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Scope 



The present document specifies interoperability tests for IMS-based IPTV system for NGN Release 3. It covers the use 
of main IPTV functionality via different methods as defined in NGN Release 2 as well as NGN Release 3 new use cases 
and features for IPTV and possible interactions with Voice/Data communications such as Social TV, Incoming Voice 
call management and notification on TV screen. Interoperability test descriptions have been specified following the 
ETSI IPT test specification framework described in EG 202 568 [i.l] and interoperability testing methodology defined 
in EG 202 237 [i.2], i.e. interoperability testing with a conformance relation. Each interoperability test description 
includes an end user test sequence as well as a table for checking of high level message flows at key standardized 
reference points in the TISPAN IMS-based IPTV infrastructure [1] and [2]. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[I] ETSI TS 182 027 (V3.4.1): "Telecommunications and Internet converged Services and Protocols 
for Advanced Networking (TISPAN); IPTV Architecture; IPTV functions supported by the IMS 
subsystem". 

[2] ETSI TS 183 063 (V3.5.2): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification". 

[3] IETF RFC 2326: "Real Time Streaming Protocol (RTSP)". 

[4] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[5] ETSI TS 102 034: "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB 

Services over IP Based Networks". 

[6] IETF RFC 3376: "Internet Group Management protocol. Version 3". 

[7] IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1". 

[8] ETSI TS 183 048: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Resource and Admission Control System (RACS); Protocol 
Signalling flows specification; RACS Stage 3". 

[9] ETSI TS 183 017 (V2.3.1): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); Resource and Admission Control: DIAMETER protocol for 
session based policy set-up information exchange between the Application Function (AF) and the 
Service Policy Decision Function (SPDF); Protocol specification". 

[10] ETSI TS 102 539: "Digital Video Broadcasting (DVB); Carnage of Broadband Content Guide 

(BCG) information over Internet Protocol (IP)". 

[II] ETSI TS 102 323: "Digital Video Broadcasting (DVB); Carriage and signalHng of TV-Anytime 
information in DVB transport streams". 
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[12] 



[13] 



[14] 



ETSI TS 181 016: "Telecommunications and Internet converged Services and Protocols for 
Advanced Networking (TISPAN); Service Layer Requirements to integrate NGN Services and 
IPTV". 

ETSI ES 283 030: "Telecommunications and Internet converged Services and Protocols for 
Advanced Networking (TISPAN); Presence Service Capability; Protocol Specification 
[3GPP TS 24.141 V7.0.0, modified and OMA-TS-Presence-SlMPLE-Vl-0, modified]". 

OMA-TS-SIMPLE-IM-V1-0-20100322-C:"OMA: Instant Messaging using SIMPLE". 



2.2 



Informative references 



The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 



[i.l] 
[i.2] 
[i.3] 
[i.4] 



ETSI EG 202 568: "Methods for Testing and Specification (MTS); Internet Protocol Testing 
(IPT); Testing: Methodology and Framework". 

ETSI EG 202 237: "Methods for Testing and Specification (MTS); Internet Protocol Testing 
(IPT); Generic approach to interoperability testing". 

K. Taniguchi and K. Ishikawa: "MSF IMS-based IPTV Test Plan for GMI 2008", Multi Service 
Forum (MSF) contribution 2008.169.06. 

SCTE-130 part 1: "Advertising Systems Overview". 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

3GPP 3'^'^ Generation Partnership Project 

A-RACS Access - Resource and Admission Control Subsystem 

AAA AA-Answer 

AAR AA-Request 

AS (IMS) Application Server 

BC Broadcast 

CF (Test) Configuration 

CoD Content On Demand 

CoDS Content on Demand Server 

CSCF Call Session Control Function 

EPG Electronic Program Guide 

FEC Forward Error Correction 

1-CSCF Interrogating CSCF 

IGMP Internet Group Management Protocol 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

IP EN IP Edge Node 

IPTV Internet Protocol Television 

MCF Media Control Function 

MDF Media Delivery Function 

MLD Multicast Listener Discovery 

nPVR network-side Personal Video Recorder 

P-CSCF Proxy CSCF 

PO Point of Observation 

PVRS Personal Video Recorder Server 

RCEF Resource Control Enforcement Function 

RTSP Real Time Streaming Protocol 

S-CSCF Serving CSCF 

SIP Session Initiation Protocol 

SDP Session Description Protocol 
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SCF Service Control Function 

SDF Service Discovery Function 

SPDF Service-based Policy Decision Function 

SSF Service Selection Function 

STA Session-Termination-Answer 

STR Session-Termination-Request 

T&A Transport and Access 

TCP Transmission Control Protocol 

TD Test Description 

TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking 

UGC User Generated Content 

UE User Equipment 

UPSF User Profile Server Function 

URI Uniform Record Identifier 



4 IMS-based IPTV Interoperability Test Specification 

4.1 Introduction 

The IMS-based IPTV interoperability test descriptions (TDs) defined in the following clauses are mainly derived from 
MSF 2008.169.06 [i.3], TS 183 063 [2] and TS 182 027 [1]. More specifically, these TDs focus on SIP/SDP [5], 
HTTP [1], RTSP [A], IGMP [6] related messaging procedures without RACS described in clauses 5, 6, 7, 8 and 11 of 
TS 183 063 [2]. TDs where RACS is involved are described in part in TS 183 048 [8]. 

The use of FLUTE and DVBSTP transport protocols on Xa reference point as well as IPv6 MLD are at this point not 
within the scope of the present document. 

4.2 Test Prerequisites 

4.2.1 IP Version and protocols 

4.2.1.1 IP 

The present document assumes that IP-based protocols all use IPv4. 

4.2.1.2 RTSP 

The present document assumes RTSP [3] messages are sent only via TCP. 

4.2.1.3 SIP 

The present document assumes that all SIP [4] messages are sent via UDP to ensure retransmission procedures based on 
SIP only and to simplify the match procedure between the message flows and real network capture. 

4.2.1.4 IGMP 

The present document assumes that IPTV aware UE requests for multicast group use IGMPv3 [6]. 

4.2.1.5 Media transport 

The present document assumes that content is transported using one of the following transport technologies: MPEG2TS 
encapsulation or direct RTP transport (e.g. H264 over RTP). Further it is assumed that transport of IPTV content within 
MPEG2-TS layer over RTP and UDP is performed according the procedures defined in TS 102 034 [5]. 
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4.2.2 Authentication and Security 

4.2.2.1 SIP 

The present document assumes that no SIP-based authentication is performed. 

4.2.2.2 HTTP 

PersonaHzed service selection is out of the scope of the document. Hence, no HTTP authentication is required from the 
UE toward SSF or SCF. Also no authentication proxy is needed between the UE and the SCF. 

4.2.3 Supported Options 

4.2.3.1 Signalling Compression 

"No SigComp" is the default signalling configuration in all test descriptions. Tests may be executed with signalling 
compression if the required nodes support it. 

4.2.3.2 SIP Provisional Message Reliability 

The present document assumes there is no use of SIP lOOrel option tag. 

4.2.3.3 SIP precondition option tag 

The present document assumes there is no use of SIP precondition option tag. 

4.2.3.4 SIP timer option tag (Session Timers) 

The present document assumes there is use of SIP timer option tag which supports session timer extension. The 
inclusion of this option tag in a Supported header field of a SIP request or response indicates that the UE is capable of 
performing refreshes. The inclusion of this option tag in a Require header of a SIP request indicates that the IMS core 
network should understand the session timer extension to process the request. Its inclusion in a Require header field of a 
SIP response indicates that the UE should look for the Session-Expires header field in the response and process it 
according to [4] . 

4.2.4 Content related options 

4.2.4.1 Encrypted contents 

The present document assumes that encryption is not used for CoD or BC content provisioning. 

4.2.4.2 Digital Rights Management 

The present document assumes DRM is not used for CoD or BC content provisioning. 

4.2.4.3 FEC 

The present document assumes that FEC disabled for CoD and BC content provisioning. 

4.2.5 Service discovery 

Service discovery should follow the procedures defined in TS 102 539 [10] and TS 102 323 [11]. 
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4.2.6 Miscellaneous 

4.2.6.1 Network Address Translation (NAT) and Firewall function 

The present document assumes there is neither NAT nor Firewall function activated. 



4.3 



Test Architecture 



In figure 1, various nodes of an IMS-based IPTV system that pertain to testing are introduced. For each node 
configuration is described and relevant points of observation (POs) are identified. Based on these nodes a static test 
architecture is defined. Figure 1 shows the abstract test architecture of an IMS -based IPTV system based on the general 
IPTV architecture defined in [2], [8] and [9]. 
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Figure 1 : IMS-based IPTV test architecture (referred as CFJMSJPTV) 

In figure 1, each node groups different IPTV logical functions. Interfaces within each node are considered internal and 
not taken into account in conformance criteria. It may however be of interest to also monitor these internal interfaces for 
debugging purposes. 

Reference points (Ut, e2 and y2 towards BC-MCF) in dotted line are not in the scope of the present document. 

NOTE: In a real IMS-based IPTV system some of the nodes shown in figure 1 may also be collocated in the same 
equipment. In this case it is however still assumed that their connecting interfaces are still available for 
monitoring purposes. 

Each node framed with a solid line is considered Equipment under Test (EUT) in the context of the ETSI 
interoperability testing methodology [i.2]. The collection of all EUTs makes up the System Under Test (SUT). Dashed 
nodes indicate other equipment, i.e. support nodes, required to execute at least some of the tests. The latter nodes are 
considered not to be part of the SUT. 
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4.3.1 



IPTV Nodes 



4.3.1.1 Core IMS 

This node contains P-CSCF, I-CSCF and S-CSCF functions as well as potentially (a part of) the UPSF. 

4.3.1.1.1 Relevant Reference Points 

The Gm reference point between the IMS Core and the IP aware UE is used as a point of observation (PO) for testing 
purposes. The ISC reference point is between the IMS Core and IPTV AS and used as a PO for testing purposes. The y2 
reference point is between the IMS Core and the PVRS and CoDS and used as a PO for testing purposes. The Gq' 
reference point is between the IMS Core and T&A and is used as a PO for testing purposes. 

4.3.1.1.2 Node Configuration 

The Core IMS should be configured to support the pre-requisites outlined in clause 4.2. 
The UPSF should be configured with the following user identities. 



Private Identity 


Public Identity 
(SIP URI) 


Public Identity 2 
(Tel URI) 


Default Public 
Identity 


Filter criteria 


userlPTV priv 


userlPTV 


na 


1 


contact IPTV AS 



4.3.1.2 IPTV aware UE 

4.3.1.2.1 Relevant Reference Points 

The Gm interface is used as a PO for interoperability tests towards the IMS Core. 

The Xa interface is used as a PO for interoperability tests towards the IPTV AS. 

The Xc and Xd (Dj) interfaces are used as POs for interoperability tests towards the PVRS, CoDS and TV Head End. 

4.3.1.2.2 Node Configuration 

The IP aware UE should be configured to support the pre-requisites outlined in clause 4.2. 

4.3.1 .3 IPTV Application Server (AS) 

This node contains SSF, SDF, and SCF functions as well as may contain also (a part of) the UPSF. 

4.3.1.3.1 Relevant Reference Points 

The Xa interface is used as a PO towards the IPTV aware UE whereas the ISC interface is used as a PO towards the 
IMS Core. 

4.3.1.3.2 Node Configuration 

The IPTV AS should be configured to support the pre-requisites outlined in clause 4.2. 

The media content available in the PVRS, CoDS and TV Head End has to be described within the IPTV AS. 

IPTV specific data information associated with the user has to be described within the IPTV AS [9]. 

4.3.1 .4 OMA Instant Messaging and Presence Service (AS) 

This node provides capabilities for Instant Messaging and Presence Service (TS 183 063 [2], clause 5.1.17.1). 
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4.3.1 .5 Content on Demand Server (CoDS) 

This node contains CoD-MCF and CoD-MDF functions and services based on CoD as UGC. 

4.3.1.5.1 Relevant Reference Points 

The y2 reference point is used as a PO between the Core IMS and the CoDS. The Xd reference point is used as PO 
between the UE and the CoDS. 

4.3.1.5.2 Node Configuration 

The CoDS should be configured to support the pre-requisites outhned in clause 4.2. 
The media contents as described in the EPGs have to be available on the CoDS. 

4.3.1 .6 Personal Video Recorder Server (PVRS) 

This node contains nPVR-MCF and nPVR-MDF functions. 

4.3.1.6.1 Relevant Reference Points 

The y2 reference point is used as a PO between the Core IMS and the PVRS. The Xd reference point is used as PO 
between the UE and the PVRS. 

4.3.1.6.2 Node Configuration 

The PVRS should be configured to support the pre-requisites outlined in clause 4.2. 
The media contents as described in the EPGs have to be available on the PVRS. 

4.3.1 .7 Transport and Access (T&A) 

This node contains transport control and processing functions, A-RACS, SPDF, NASS and RCEF. The latter is located 
in the IP-Edge Node. 

4.3.1.7.1 Relevant Reference Points 

The Xd, Xc and Dj reference points are used as POs between the UE and the transport node. 
Gq' reference point is used as Pos between SPDF and CORE IMS. 

4.3.1.7.2 Node Configuration 

The T&A should be configured to support the pre-requisites outlined in clause 4.2. 

Regarding multicast support, the function has to implement IGMPv3, IGMPv2 with SSM (source specific mapping) and 
in case the multicast sources are not directly connected a CORE network a multicast protocol (e.g.: PIM). 

4.3.2 External Nodes 

This clause lists nodes which are required for performing some of the interoperability tests but not consider to be part of 
the SUT, i.e. supporting equipment required for the execution of tests. 

4.3.2.1 TV Head End 

This node contains BC-MDF and BC-MCF functions. 
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4.3.2.1 .1 Relevant Reference Points 

The Xd reference point is used as PO between the UE and the TV Head End. 

y2 reference point is used between CORE IMS and BC-MCF. It is not a PO so far. 

4.3.2.2 Node Configuration 

The TV Head End should be configured to support the pre-requisites outlined in clause 4.2. 
TV End Head should provide at least one BC channel unconditionally. 

4.3.2.3 Time Shifted TV Server 

This node contains TsTV-MDF and TsTV -MCF functions. 

4.3.2.3.1 Relevant Reference Points 

The Xd reference point is used as PO between the UE and the TsTV Server. 

y2 reference point is used between CORE IMS and TsTV-MCF. It is not a PO so far. 

4.3.2.4 Node Configuration 

The TsTV Server should be configured to support the pre-requisites outlined in clause 4.2. 

4.3.2.5 Advertising Nodes 

The nodes described below are involved in the different types of Advertising architecture (TS 182 027 [1], clause 8.4 
and annex E). 

4.3.2.5.1 Internal Advertising Nodes 

NOTE: Internal Advertising Nodes not covered by the present document. 

4.3.2.5.2 SCTE-130 Advertising Nodes 

This is the Advertising architecture defined by SCTE-130 ([i.4]). TISPAN and SCTE-130 entities communicate through 
three AD interfaces are: ADz, ADx and ADy. 

4.3.2.5.2.1 Relevant Reference Points 

ADz reference point is used as PO between the UE and the external SCTE-130 Advertizing Sub-system. 
ADx reference point is used between SCF and the external SCTE-130 Advertizing Sub-system. 
ADy reference point is used between MCF and the external SCTE-130 Advertizing Sub-system. 

4.3.2.5.3 OMA MobAd Advertising Nodes 

NOTE: OMA MobAd Advertising Nodes not covered by the present document. 
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4.3.3 Summary of interfaces and protocols 

Figure 1 includes also IPTV reference points to be monitored in interoperability testing. 

Figure 2 identifies again the relevant reference points and provides more information about the protocols they use. 



FEZ 
Reference 

point 
(protocol) 



UE 



IMS core 



UE 






IMS core 



UPSF 



Cx 

(Diameter) 




telP/SDP]/ 

5^ 



SglP/SDg/ 



UPSF 



Cx 
(Diameter) 



(Diameter) 



■gr 

(Diameter) 



SDF 



via Core 

IIVIS 
(SIP/SDR) 



ISC 
(SIP/SDR) 



Sh 
(Diameter) 




Ss' 

(not 

defined) 



SCF 



Ut 
(HTTR), 
via Core 

IIVIS 
(SIR/SDR) 



K§IP/SDg/ 



Sh 
(Diameter) 



Ss' 

(not 

defined) 



Xora 
'llVISand 
y2 
;iR/SDR), 



MCF 




iaCo75 
IIVIS and y2^ 



Xp 

(not 

defined) 



MDF 



/UDR/RTP/\ 
RTCR/HTT 



Xp 

(not 
defined) 



ECF/ EFF 



Dj, Di 
IGIVIR/IVILD 



NOTE 1 : As described in TS 182 027 [1], clauses 6.4 and 6.5, Xc and Xd are logical reference points that can be 
decomposed into Dj and possibly Di, Ds or Iz reference points depending on the location of the MCF or 
IVIDF, and the HTTP is used for the content download. 

NOTE 2: Annex IH lists compliance requirements for the protocols listed in this table. 



Figure 2: Summary of relevant reference points and protocols 

In addition, Gq' between IMS Core and TA carries diameter protocol. 

4.3.4 Methocd 1 and Method 2 

In the interoperability test descriptions defined in the present document, two methods regarding the procedures using 
RTSP for IMS-based IPTV are used. More information on these methods is available in clause 7 and annex Q of [2]. 

4.4 Test Descriptions 

This clause defines IMS-based IPTV interoperability test descriptions (TD) for systems composed of equipment by 
different vendors. Each TD includes a test sequence describing user interactions with IPTV equipment as well as 
messages exchanged between IPTV equipment at selected standardized reference points. 

TD identifiers are constructed from a test suite identifier, a test group identifier and a test number. Table 1 summarizes 
the main identifiers used in the present document. 
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Table 1 : Summary of TD identifier prefixes 



Test Description 
Identifier Prefix 


Scope of the test 


Clause 




TD_IMS_IPTV_ADS 


Service attachment, 
discovery and selection 


4.4.1 


4.4.1 .1 Manual configuration of SSF 

information in pull mode 

4.4.1 .2Automatic provisioning of SSF in pull 

mode 

4.4.1 .3 Automatic provisioning of SSF in 

push mode 


TD_IMS_IPTV_BC 


Broadcast TV 


4.4.2 


4.4.2.1 Session initiation without RACS 
4.4.2.2Channel Zapping without RACS 
4.4.2.3Session termination without RACS 
4.4.2.4Session initiation with RACS 
4.4.2.5Channel Zapping with RACS 
4.4.2.6Session termination with RACS 


TD_IMS_IPTV_BC1 


Broadcast TV with trick 
mode using method 1 


4.4.3 


4.4.3.1 Initiate trick-play on a live broadcast 
channel 

4.4.3.2 Play in trick-play mode 
4.4.3.3 Simple fast forward trick-play 

4.4.3.4 Fast backward trick-play to beginning 
of recorded content 

4.4.3.5 Fast forward to move from trick-play 
to live broadcast mode 


TD_IMS_IPTV_BC2 


Broadcast TV with trick 
mode using method 2 


4.4.4 


4.4.4.1 Initiate trick-play on a live broadcast 
channel 

4.4.4.2 Play in trick-play mode 
4.4.4.3 Simple fast forward trick-play 
4.4.4.5 Fast forward to move from trick-play 
to live broadcast mode 


TD_IMS_IPTV_CoD1 


Content on Demand using 
method 1 


4.4.5 


4.4.5.1 Start CoD 

4.4.5.2 Pause CoD with trick-play 

4.4.5.3 Play CoD in trick-play mode 
4.4.5.4 Simple fast forward of CoD using 
trick-play 

4.4.5.5Simple fast backward on CoD using 

trick-play 

4.4.5.6Jump to specific location in CoD 

content 

4.4.5.7Quit watching CoD 

4.4.5.8 Resume CoD 

4.4.5.9CoD termination by IPTV AS 

4.4.5.10 End of CoD 


TD_IMS_IPTV_CoD2 


Content on Demand using 
method 2 


4.4.6 


4.4.6.1 Start CoD 

4.4.6.2 Pause CoD with trick-play 

4.4.6.3 Play CoD with trick-play 

4.4.6.4 Fast forward CoD using trick-play 

4.4.6.5 Fast backward CoD using trick-play 
4.4.6.6Jump to specific location in CoD 
content 

4.4.6.7Terminate CoD 

4.4.6.8 Resume CoD 

4.4.6.9CoD termination by IPTV AS 

4.4.6.10 CoD termination at the end of 

stream 


TD_IMS_IPTV_nP1 


nPVR using method 1 


4.4.7 


4.4.7.1 Impulsive recording request 
4.4.7.2Scheduled recording request 
4.4.7.3Watching a recorded nPVR content 


TD_IMS_IPTV_nP2 


nPVR using method 2 


4.4.8 


4.4.8.1 Impulsive recording request 
4.4.8.2Scheduled recording request 
4.4.8.3Watching a recorded content 


TD_IMS_IPTV_UGC 


User Generated Content 
(UGC) 


4.4.9 


4.4.9.1 UGC declaration procedures 

4.4.9.2 UGC creation procedures 

4.4.9.3 UGC Watching procedures 


TD IMS IPTV Not 


Notification 


4.4.10 


4.4.10.1 Sending Notification 


TD_IMS_IPTV_IM 


Instant Messaging 


4.4.11 


4.4.1 1 .1 Instant Messaging sending 

4.4.1 1.2 Instant Messaging receiving 
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Test Description 
Identifier Prefix 


Scope of the test 


Clause 




TD_IMS_IPTV_pCoD 


PushCod 


4.4.12 


4.4.12.1 UE-initiated Content download for 
unicast download 

4.4.12.2 UE-initiated Content download for 
unicast progressive download 


TD_IMS_IPTV_TAI2 


Targeted Ad Insertion - 
SCTE 


4.4.13 


4.4.13.1 TAI by notification at UE side 

4.4.13.2 TAI by content insertion at UE side 

4.4.13.3 TAI by content insertion at MF side 


TD_IMS_IPTV_EMI 


Emergency Information 


4.4.14 


4.4.14.1 Emergency Information by 
Notification 

4.4.14.2 Emergency Information by Content 
Insertion 


TD_IMS_IPTV_ICM 


Incoming call 
management 


4.4.15 


4.4.15.1 Incoming call notification 

4.4.15.2 Incoming call handling 

4.4.15.3 Incoming call rejection 

4.4.15.4 Incoming call acceptance on IPTV 
UE 

4.4.15.5 Incoming call forwarding to other 
UE 


TD IMS IPTV TsTV 


Time Shifted TV 


4.4.16 


4.4.16.1 Watching a recorded TsTV content 


TD_IMS_IPTV_PC 


Parental Control 


4.4.17 


4.4.17.1 Parental control applied for BC 

4.4.17.2 Parental control applied for CoD 

4.4.17.3 Parental control applied for UGC 

4.4.17.4 Parental control applied for PVR 


TD_IMS_IPTV_CM 


Content Marker Service 
(CM) 


4.4.18 


4.4.18.1 Content Marker Creation 

4.4.18.2 Content Marker handling 

4.4.18.3 Content Marker presentation 

4.4.18.4 Content Marker usage 


TD_IMS_IPTV_CR 


Content Recommendation 
(CR) 


4.4.19 


4.4.19.1 Content Recommendation profile 
configuration 

4.4.19.2 Content Recommendation by 
notification 


TD_IMS_IPTV_PRE 


Presence 


4.4.20 


4.4.20.1 Subscribing to presence 

4.4.20.2 Receiving presence notifications 


TD_IMS_IPTV_ST2 


Service Continuation 


4.4.21 


4.4.21.1 Service Continuation between IPTV 
UEs 



4.4.1 Service Attachment, Service Discovery and Selection 

In the following TDs, we consider step 1 of the IPTV Aware UE start-up procedure, i.e. Network attachment (UE to 
NASS), as being out of the scope of the test. 
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4.4.1 .1 Manual configuration of SSF information in pull mode 



Interoperability Test Description 


Identifier: 


ID IMS IPTV ADS 0001 (MSF S3A-0101) 


Summary: 


UE displays EPG with manual SSF address configuration 


References: 


TS 182 027 [1], clause 8.2; TS 183 063 [2], clause 6.1.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS 


^^^■- 


Pre-test 
conditions: 


• IPTV AS is configured not to act as a third-party registrar (push mode is disabled) 

• UE is configured statically with SSF information 

• UE and IPTV AS support the same EPG format 


^^r- ■ 1 


Test Sequence: 


Step 


SB 


1 


User starts UE 


2 


User requests EPG 


3 


Verify that UE displays EPG 


^^^M— 


Conformance 
Criteria: 


Check 


^ 


1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 








1 




i 














User starts UE 


2 










V 






SIP 


UE sends SIP REGISTER to CORE via Gm 


^ 




3 


SIP 


CORE sends SIP 200 OK to UE via Gm 






4 


HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 








5 


HTTP 


AS sends HTTP 200 OK to UE via Xa (1 to n 
times) 








6 

7 




^ 

i 














User requests EPG 
UE displays EPG 



Steps 4 and 5 may be repeated multiple times. Each HTTP message pair carries information (EPG) different from 
vendors. 
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4.4.1 .2 Automatic provisioning of SSF in pull mode 



Interoperability Test Description 


Identifier: 


ID IMS IPTV ADS 0002(MSFS3A-0101) 


Summary: 


UE displays EPG with automatic SSF provision in pull mode 


References: 


TS 1 82 027 [1 ], clause 8.2; TS 1 83 063 [2], clauses 5.1 .2.2 and 6.1 .1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS 


^^^■- 


Pre-test 
conditions: 


• IPTV AS is configured not to act as a third-party registrar (push mode is disabled) 

• Gore IMS is configured to forward service attachment information request to IPTV 
AS 

• UE is configured to request the EPG 

• UE and IPTV AS support the same EPG format 


L 1 


Test Sequence: 


Step 




1 


User starts UE 


2 


User requests EPG 


3 


Verify that UE displays EPG 


-^^^m_ 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 








1 




J 














User starts UE 


2 








V 








SIP 


UE sends SIP REGISTER to CORE via Gm 






3 


SIP 


CORE sends SIP 200 OK to UE via Gm 






2 


SIP 


UE sends SIP SUBSCRIBE to CORE via Gm 


^ 




3 


SIP 


CORE sends SIP SUBSCRIBE to AS via ISC 


f 


4 


SIP 


AS sends SIP 200 OK to CORE via ISC 




5 


SIP 


CORE sends SIP 200 OK to UE via Gm 






6 


SIP 


AS sends SIP NOTIFY to CORE via ISC 


V 


7 


SIP 


CORE sends SIP NOTIFY to UE via Gm 




N. 


8 


SIP 


UE sends SIP 200 OK to CORE via Gm 






9 


SIP 


CORE sends SIP 200 OK to AS via ISC 


V 


10 


HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 


^ 






11 

12 
13 


HTTP 


AS sends HTTP 200 OK to UE via Xa (1 to n 

times) 

User requests EPG 

UE displays EPG 

















Steps 10 and 1 1 can be repeated multiple times. Each HTTP message pair carries information different from vendors. 
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4.4.1 .3 Automatic provisioning of SSF in push mode 



Interoperability Test Description 


Identifier: 


ID IMS IPTV ADS 0003{MSFS3A-0101) 


Summary: 


UE can display EPG with automatic SSF provision in push mode 


References: 


TS 182 027 [1], clause 8.2; TS 183 063 [2], clauses 5.1.2.1 and 6.1.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS 


^^^■- 


Pre-test 
conditions: 


• IPTV AS is configured to act as a third-party registrar (push mode enabled) 

• UPSF is configured to provide SSF information to SDF 

• UE is configured for SSF provision in push mode 

• UE and IPTV AS support the same EPG format 


Test Sequence: 


Step 




1 


User starts UE 


2 


User requests EPG 


3 


Verify that UE displays EPG 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 








1 




^ 














User starts UE 


2 










V 






SIP 


UE sends SIP REGISTER to CORE via Gm 


^ 




3 


SIP 


GORE sends SIP 200 OK to UE via Gm 






4 


SIP 


CORE sends SIP REGISTER to AS via ISC 


' 


5 


SIP 


AS sends SIP 200 OK to CORE via ISC 




6 


SIP 


AS sends SIP MESSAGE to CORE via ISC 


V 


7 


SIP 


CORE sends SIP MESSAGE to UE via Gm 




N. 


8 


SIP 


UE sends SIP 200 OK to CORE via Gm 






9 


SIP 


CORE sends SIP 200 OK to AS via ISC 


V 


10 


HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 


^ 






11 

12 
13 


HTTP 


AS sends HTTP 200 OK to UE via Xa (1 to n 

times) 

User requests EPG 

UE displays EPG 




-^ 













Steps 10 and 1 1 can be repeated multiple times. Each HTTP message pair carries information different from 
vendors. 
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4.4.2 Broadcast TV 



4.4.2.1 Session initiation without RAGS 



Interoperability Test Description | 


Identifier: 


ID IMS IPTV BC 0001 (S3A-02G1) 


Summary: 


User requests to watch broadcast TV channel 


References: 


TS 182 027 [1], clause 8.3.1 ; TS 183 063 [2], clauses 5.1 .3.1 and 8.1 .2.1 


Configuration: 


OF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A 


r" 




Pre-test 
conditions: 


• UE is registered in Core IMS and received EPG from IPTV AS 
(see TD_ IMS_IPTV_ADS_0001/2/3) 

• EPG has at least one broadcast channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End 

• UE is configured not to request QoS 


I 


J 


Test Sequence: 


Step 




1 


User requests to watch a broadcast TV channel 


2 


Verify that UE displays the selected broadcast TV channel 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


c 


R 

E 


A 
S 








1 




J 














User requests to watch a broadcast TV channel 


2 








V 








SIP 


UE sends SIP INVITE to CORE via Gm 


^ 




3 


SIP 


CORE sends SIP INVITE to AS via ISC 




4 


SIP 


AS sends SIP 200 OK to CORE via ISC 


V 


5 


SIP 


CORE sends SIP 200 OK to UE via Gm 




N. 


6 


SIP 


UE sends SIP ACK to CORE via Gm 






7 


SIP 


CORE sends SIP ACK to AS via ISC 




8 


IGMP 


UE sends IGMP JOIN to T&A via Dj 




9 
10 




i 




N. 


V 






SIP 


UE displays the selected broadcast TV channel 
UE sends SIP INFO to CORE via Gm 






11 


SIP 


CORE sends SIP INFO to AS via ISC 





















The SIP INFO messages are sent out with a delay after IGMP join message. If the channel is changed again within the 
delay, the INFO message is not sent out. 

There is no strict sequence of the SIP and IGMP messages. The IGMP JOIN message may be sent before or after 
sending SIP ACK. 
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4.4.2.2 Channel Zapping without RAGS 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC 0002{S3A-0301) 


Summary: 


User changes to a HD channel while watching a SD broadcast TV 


References: 


TS 1 82 027 [1 ], clause 8.3.4; TS 1 83 063 [2], clauses 5.1 .3.5 and 8.1 .2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A 


^^^■- 


Pre-test 
conditions: 


• UE is registered in Gore IMS and displaying a broadcast TV channel 
(see TD_IMS_IPTV_BC_0001) 

• The EPG has at least 2 broadcast channels 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End 

• UE is configured not to request QoS 




Test Sequence: 


Step 




1 


User changes to another broadcast TV channel 


2 


Verify that UE displays the other broadcast TV channel 


^^^^~ 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 




» 














User changes to another broadcast TV channel 


2 








V 


V 






IGMP 


UE sends IGMP LEAVE INFO to T&A via Dj 




3 


SIP 


UE sends SIP re-INVITE to CORE via ISC 
(optional) 


^ 




4 


SIP 


CORE sends SIP re-INVITE to AS via ISC 
(optional) 


^ 


5 


SIP 


AS sends SIP OK to CORE via ISC (optional) 




6 


SIP 


CORE sends SIP OK to UE via ISC (optional) 






7 


IGMP 


UE sends IGMP JOIN INFO to T&A via Dj 




8 




^ 














Verify that UE displays the other broadcast TV 
channel 




9 










N. 






SIP 


UE sends SIP INFO to AS via ISC 






10 


SIP 


CORE sends SIP INFO to AS via ISC 





















The SIP INFO messages are sent out with a delay after an IGMP JOIN message. If the channel is changed again within 
the delay, the SIP INFO message is not sent out. 
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4.4.2.3 Session termination witliout RAGS 



Interoperability Test Description 


Identifier: 


ID IMS IPTV BC 0003{S3A-0401) 


Summary: 


User quits watching broadcast TV 


References: 


TS 182 027 [1], clause 8.4.1; TS 183 063 [2], clauses 5.1.4.2 and 7.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A 




Pre-test 
conditions: 


• User is registered in Gore IMS using userlPTV_priv identity 

• UE is displaying a broadcast TV channel 
(see TD_IMS_IPTV_BG_0001) 

• EPG has at least one broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End 

• UE is configured not to request QoS 


L 1 


Test Sequence: 


Step 




1 


User quits watching the broadcast TV channel 


2 


Verify that the UE does not display the broadcast TV channel anymore 


1 1 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 




» 














User quits watching the broadcast TV channel 


2 
















IGMP 


UE sends IGMP LEAVE INFO to T&A via Dj 




3 




^ 














UE does not display the broadcast TV channel 
anymore 




4 
















SIP 


UE sends SIP BYE to GORE via Gm 






5 


SIP 


GORE sends SIP BYE to AS via ISG 


' 


6 


SIP 


AS sends SIP 200 OK to GORE via ISG 




7 


SIP 


GORE sends SIP 200 OK to UE via Gm 
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4.4.2.4 Session initiation witli RAGS 



Interoperability Test Description 


Identifier: 


TD IMS IPTV BC 0004 


Summary: 


User requests to watch broadcast TV channel using QoS 


References: 


TS 182 027 [1], clause 8.3.1 ;TS 183 063 [2], clauses 5.1.3.1 and 8.1.2.1, 
TS 183 017 [9], clauses 5.1 .1 and 5.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE is registered in Core IMS and received EPG from IPTV AS 
(see TD_ IMS_IPTV_ADS_000 1/2/3) 

• EPG has at least one broadcast channel 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End 

• UE is configured to request QoS 






Test Sequence: 


Step 




1 


User requests to watch a broadcast TV channel 


2 


Verify that UE displays the selected broadcast TV channel 


^^^^g^p 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 




^ 














User requests to watch a broadcast TV channel 


2 








V 


N. 






SIP 


UE sends SIP INVITE to CORE via Gm 
(SDP Bandwidth "b=" option is populated 
through EPG related information or static 
configuration) 






3 


SIP 


CORE sends SIP 100 Trying to UE via Gm 






4 


Diameter 


CORE sends AAR to T&A via Gq' 


V 


5 


Diameter 


T&A sends AAA to CORE via Gq' 
(Result-Code = DIAMETER SUCCESS) 




6 


SIP 


CORE sends SIP INVITE to AS via ISC 


^ 


7 


SIP 


AS sends SIP 200 OK to CORE via ISC 


V 


8 


Diameter 


CORE sends AAR to T&A via Gq' 


N. 


9 


Diameter 


T&A sends AAA to CORE via Gq' 
(Result-Code = DIAMETER SUCCESS) 




10 


SIP 


CORE sends SIP 200 OK to UE via Gm 




N. 


11 


SIP 


UE sends SIP ACK to CORE via Gm 






12 


SIP 


CORE sends SIP ACK to AS via ISC 




13 

H A 


IGMP 


UE sends IGMP JOIN to T&A via Dj 




15 




^ 






N. 






SIP 


Ut displays the selected broadcast I V channel 
UE sends SIP INFO to CORE via Gm 






16 


SIP 


CORE sends SIP INFO to AS via ISC 





















The SIP INFO messages are sent out with a delay after IGMP join message. If the channel is changed again within the 
delay, the INFO message is not sent out. 

There is no strict sequence of the SIP and IGMP messages. The IGMP JOIN message may be sent before or after 
sending SIP ACK. 

The diagram above shows a two phases method on Gq' reference point (see clause 5.1.1 of [10]). Step 5 request is for 
resource reservation, step 10 for resource commitment. Alternatively, steps 10 and 1 1 could be omitted if step 5 
requests resource commitment (Flow-Status is different of DISABLED). 
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4.4.2.5 Channel Zapping with RAGS 



Interoperability Test Description 



Identifier: 



TD IMS IPTV BC 0005 



Summary: 



User changes to a HP channel while watching SD broadcast TV using QoS 



References: 



TS 182 027 [1], clause 8.3.4; TS 183 063 [2], clauses 5.1.3.5 and 8.1.2; 
TS 1 83 017 [9], clauses 5.1 .2 and 5.2.2 



Configuration: 



CF IMS IPTV 



Required 
Equipment: 



Pre-test 
conditions: 



Test Sequence: 



IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A 



UE is registered in Core IMS and displaying a broadcast TV channel 

(see TD_IMS_IPTV_BC_0001) 

The EPG has at least 2 broadcast channels 

TV Head End broadcasting TV content in real-time using multicast 

UE supports content protocols and coding used by TV Head End 

UE is configured to request QoS 



Step 



User changes to another broadcast TV channel 



Verify that UE displays the other broadcast TV channel 



Conformance 
Criteria: 



Check 



1 



Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 




^ 














User changes to another broadcast TV channel 


2 








V 








IGMP 


UE sends IGMP LEAVE INFO to T&A via Dj 




3 


SIP 


UE sends SIP re-INVITE to CORE via ISC 






4 


Diameter 


CORE sends AAR to T&A via Gq' 




5 


Diameter 


T&A sends AAA to CORE via Gq' 


^ 


6 


SIP 


CORE sends SIP re-INVITE to AS via ISC 


^ 


7 


SIP 


AS sends SIP OK to CORE via ISC 




8 


Diameter 


CORE sends AAR to T&A via Gq' 




9 


Diameter 


T&A sends AAA to CORE via Gq' 




10 


SIP 


CORE sends SIP OK to UE via ISC 






11 


IGMP 


UE sends IGMP JOIN to T&A via Dj 




12 




^ 














Verify that UE displays the other broadcast TV 
channel 




13 








V 








SIP 


UE sends SIP INFO to AS via ISC 






14 


SIP 


CORE sends SIP INFO to AS via ISC 





















The diagram above shows a two phases method on Gq' reference point (see clause 5.1.1 of [10]). Step 4 request is for 
resource reservation, step 8 for resource commitment. Alternatively, steps 8 and 9 could be omitted if step 4 requests 
resource commitment (Flow-Status is different of DISABLED). 
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4.4.2.6 Session termination with RAGS 



Interoperability Test Description 



Identifier: 



TD IMS IPTV BC 0006 



Summary: 



User quits watching broadcast TV using QoS 



References: 



TS 1 82 027 [1 ], clause 8.4.1 ; TS 1 83 063 [2], clauses 5.1 .4.2 and 7.2.1 ; 
TS 1 83 017 [9], clauses 5.1 .3 and 5.2.3 



Configuration: 



CF IMS IPTV 



Required 
Equipment: 



Pre-test 
conditions: 



c 



IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A 



User is registered in Core IMS using userlPTV_priv identity 

UE is displaying a broadcast TV channel 

(see TD_IMS_IPTV_BC_0001) 

EPG has at least one broadcast TV channel 

TV Head End broadcasting TV content in real-time using multicast 

UE supports content protocols and coding used by TV Head End 

UE is configured to request QoS 



Test Sequence: 



Conformance 
Criteria: 



Step 



User quits watching the broadcast TV channel 



Verify that the UE does not display the broadcast TV channel anymore 



Cfieck 



30^ 



1 [Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 




> 














User quits watching the broadcast TV channel 


2 
















IGMP 


UE sends IGMP LEAVE INFO to T&A via Dj 




3 




^ 














UE does not display the broadcast TV channel 
anymore 




4 
















SIP 


UE sends SIP BYE to CORE via Gm 






5 


Diameter 


CORE sends STR to T&A via Gq' 




6 


Diameter 


T&A sends STA to CORE via Gq' 




7 


SIP 


CORE sends SIP BYE to AS via ISC 


f 


8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 



















4.4.3 Broadcast TV with trick-play using Method 1 

More information about Method 1 is given in clause 4.3.4. 
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4.4.3.1 Initiate trick-play on a live broadcast channel 



Interoperability Test Description 



Identifier: 



TD_IMS_IPTV_BC1_0001 (S3A-0501) 



Summary: 



User initiates trick mode while watching a broadcast TV channel 



References: 



TS 182 027 [1], clause 8.3.5; TS 183 063 [2], clauses 5.1.3.3.1 and 8.1.2.2 



Configuration: 



CF ll\/IS IPTV 



Required 
Equipment: 

Pre-test 
conditions: 



IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A, CoDS 



Test Sequence: 



UE, CoDS, Core IIVIS and IPTV AS are configured for method 1 

User is registered in Core IIVIS using userlPTV_priv identity 

UE is displaying a trick-play enabled broadcast TV channel 

(see TD_IIVIS_IPTV_BC_0001) 

EPG has at least one trick play enabled broadcast TV channel 

T&A is configured with multicast rights for the UE 

TV Head End broadcasting TV content in real-time using multicast 

UE supports content protocols and coding used by TV Head End and CoDS 

CoDS supports content protocols and coding used by TV Head End 

User has trick-play rights in IPTV AS 

CoDS is recording the trick play enabled broadcast channel 



Step 



User requests a pause on the broadcast TV channel 



Verify that the UE freezes the image of the broadcast TV channel 



Conformance 
Criteria: 



Check 



1 



Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 


















User requests a pause on the broadcast TV 
channel 




2 












V 


SIP 


UE sends SIP RE-INVITE to CORE via Gm 


f 




3 


SIP 


CORE sends SIP RE-INVITE to AS via ISC 


^ 


4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 




N. 


7 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 




V 


10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


IGMP 


UE sends IGMP LEAVE to T&A via Dj 




15 




f 














UE freezes the image of the broadcast TV 
channel 





















It is acceptable to generate SIP UPDATE instead of re INVITE requests. In that case SIP ACK requests should not be 
sent. 

There is no strict sequence of SIP and IGMP messages. The IGMP LEAVE message may be sent before or after 
sending SIP ACK. 
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4.4.3.2 Play in trick-play mode 



Interoperability Test Description 


Identifier: 


ID IMS IPTV BC1 0002{S3A-0601) 


Summary: 


User requests the normal play mode on a broadcast TV channel in trick play mode 


References: 


TS 182 027 [1]; TS 183 063 [2], clause 7.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 




Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying frozen trick-play enabled broadcast TV channel 
(see TD_IMS_IPTV_BC1_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS 

• CoDS is recording the trick play enabled broadcast channel 




Test Sequence: 


Step 


1 


1 


User requests play on the paused broadcast TV channel 


2 


Verify that UE displays the recorded broadcast TV channel content 


1 1 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 


















User requests play on the paused broadcast TV 
channel 




2 
















RTSP 


UE sends RTSP PLAY to CoDS via Xc 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 


















Verify that UE displays the recorded broadcast 
TV channel content 





















A RTSP PAUSE message may be sent between two consecutive RTSP PLAY messages. 
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4.4.3.3 Simple fast forward trick-play 



Interoperability Test Description 


Identifier: 


ID IMS IPTV BC1 0003{S3A-0601) 


Summary: 


User requests fast forward on a paused broadcast TV channel in trick play mode 
without reaching the end of recording 


References: 


TS 182 027 [11; TS 183 063 [2], clause 7.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying frozen trick-play enabled broadcast TV channel 
(see TD_IMS_IPTV_BC1_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS 

• CoDS is recording the trick play enabled broadcast channel 




Test Sequence: 


Step 




1 


User requests x2 fast forward on the paused broadcast TV channel 


2 


Verify that UE displays recorded broadcast TV channel in fast forward 
mode 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 


















User requests x2 fast forward on the paused 
broadcast TV channel 




2 












V 




RTSP 


UE sends RTSP PLAY (scale -h2) to CoDS via 
Xc 


^ 








3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 




f 














UE displays recorded broadcast TV channel in 
fast forward mode. 





















A RTSP PAUSE message may be sent between two consecutive RTSP PLAY messages. 
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4.4.3.4 Fast backward trick-play to beginning of recorded content 



Interoperability Test Description 


Identifier: 


ID IMS IPTV BC1 0004{S3A-0701) 


Summary: 


User requests fast backward on a paused broadcast TV channel in trick play mode 
until the beginning of the recording is reached 


References: 


TS 182 027 [11; TS 183 063 [2], clause 7.2.1 


Configuration: 


OF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE, GoDS, Gore IMS and IPTV AS are configured for method 1 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying paused recorded broadcast TV channel 
(see TD_IMS_IPTV_BC1_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and GoDS 

• GoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS 

• GoDS is recording the trick play enabled broadcast TV channel 




Test Sequence: 
1 


Step 




1 


User requests x2 fast backward on the paused broadcast TV channel 


2 


Verify that UE displays recorded broadcast TV channel in fast backward 
mode 


3 

J 


Verify that UE stops display when beginning of recording is reached 


1 

Conformance 
Criteria: 


I 
Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 




V 














User requests x2 fast backward on the paused 
broadcast TV channel 




2 
















RTSP 


UE sends RTSP PAUSE to GoDS via Xc 
(optional) 


^ 








3 


RTSP 


GoDS sends RTSP 200 OK to UE via Xc 
(optional) 








V 


4 


RTSP 


UE sends RTSP PLAY (scale -2) to GoDS via 
Xc 










5 


RTSP 


GoDS sends RTSP 200 OK to UE via Xc 










6 


















UE displays recorded broadcast TV channel in 
fast backward mode 




7 




f 














UE stops display when beginning of recording is 
reached 
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4.4.3.5 Fast forward to move from trick-play to live broadcast mode 



Interoperability Test Description 


Identifier: 


ID IMS IPTV BC1 0005{S3A-0801) 


Summary: 


User requests fast forward until the end of recording is reached and moves from trick 
play to live broadcast TV channel 


References: 


TS 1 82 027 [1], clause 8.3.6; TS 183 063 [2], clauses 5.1 .3.3.2, 7.2.1 and 8.1 .2.1 


Configuration: 


OF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE, GoDS, Gore IMS and IPTV AS are configured for method 1 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying paused recorded broadcast TV channel 
(see TD_IMS_IPTV_BC1_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and GoDS 

• GoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS. 

• GoDS is recording the trick play enabled broadcast TV channel 

• UE is configured to change to live broadcast automatically after trick play ends 




Test Sequence: 


Step 




1 


User requests x2 fast forward on a paused broadcast TV channel 


2 


Verify that UE displays recorded broadcast TV channel in fast forward 
mode 


3 


Verify that UE displays live broadcast TV channel when end of recording is 
reached 


^^H^B_ 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 














1 


















User requests x2 fast forward on a paused 
broadcast TV channel 




2 












■N. 




RTSP 


UE sends RTSP PLAY(scale +2) to CoDS via 
Xc 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 


















UE displays recorded broadcast TV cliannel in 
fast forward mode 


5 






^ 










RTSP 


CoDS sends RTSP ANNOUNCE to UE via Xc 








>. 


6 


RTSP 


UE sends RTSP 200 OK to CoDS via Xc 






























7 












^. 




IGMP 


UE sends IGMP JOIN to T&A via Dj 




8 


SIP 


UE sends SIP REINVITE to CORE via Gm 






9 


SIP 


CORE sends SIP REINVITE to AS via ISC 




10 


SIP 


AS sends SIP BYE to CORE via ISC 




11 


SIP 


CORE sends SIP BYE to CoDS via y2 


^ 




12 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






13 


SIP 


CORE sends SIP 200 OK to AS via ISC 




14 


SIP 


AS sends SIP 200 OK to CORE via ISC 




15 


SIP 


CORE sends SIP 200 OK to UE via Gm 






16 


SIP 


UE sends SIP ACK to CORE via Gm 






17 


SIP 


CORE sends SIP ACK to AS via ISC 




18 


















UE displays live broadcast TV channel when 
end of recording is reached 


i 





















Upon receipt of the end-of-stream indication the CoDS sends in step 5 an RTSP ANNOUNCE to the UE with an 
indication that the end-of-stream has been reached. In case of BC sessions with trick-play, if the UE receives an RTSP 
ANNOUNCE request with an end-of-stream indication, the UE may initiate a session modification procedure in order 
to go back to a normal BC session in multicast mode (this is the case described above) or may alternatively take other 
actions (e.g. rewind, pause, terminate session, etc.). 

There is a delay between the UE receiving the RTSP ANNOUCE in step 5 and sending the SIP relNVITE in step 8. 

It is acceptable to generate SIP UPDATE instead of SIP relNVITE requests. In that case SIP ACK requests should not 
be sent. 

Before the RTSP PLAY message in step 2 a RTSP PAUSE message may be sent. 

There is no strict sequence of the SIP and IGMP messages. The IGMP JOIN message may be sent before or after 
sending the SIP ACK request. 

4.4.4 Broadcast TV with trick-play using Metinod 2 

More information about Method 2 is given in clause 4.3.4. 
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4.4.4.1 Initiate trick-play on a live broadcast channel 



Interoperability Test Description 


Identifier: 


ID IMS IPTV BC2 0001 {S3A-0502) 


Summary: 


User initiates tricl< mode while watching a broadcast TV channel 


References: 


TS 182 027 [1], clause 8.3.5; TS 183 063 [2], clauses 5.1.3.3.1 and 8.1.2.2 


Configuration: 


OF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV HEAD END, T&A, CoDS 




Pre-test 
conditions: 


• UE, GoDS, Gore IMS and IPTV AS are configured for method 2 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying a trick-play enabled broadcast TV channel 
(see TD_IMS_IPTV_BC_0001) 

• EPG has at least one broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and GoDS 

• GoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS. 

• GoDS is recording the trick play enabled broadcast channel 


^^^ ^^^ 


Test Sequence: 


Step 


1 


1 


User requests to pause on the broadcast TV channel 


2 


Verify that the UE freezes the image of the broadcast TV channel 


1 1 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


c 

o 
D 
S 














1 


















User requests to pause on the broadcast TV 
channel 


5 




2 










V 






SIP 


UE sends SIP RE-INVITE to CORE via Gm 






3 


SIP 


GORE sends SIP RE-INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 


^ 




6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 


*. 


V 


7 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


8 


SIP 


AS sends SIP 200 OK to CORE via ISC 


*. 


9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 


^ 


12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


RTSP 


UE sends RTSP DESCRIBE to CoDS via Xc 










15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 








>. 


16 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 


^ 








17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 








■N. 


18 


SIP 


UE sends SIP REINVITE to CORE via Gm 






19 


SIP 


CORE sends SIP REINVITE to AS via ISC 




20 


SIP 


AS sends SIP REINVITE to CORE via ISC 




21 


SIP 


CORE sends SIP INVITE to CoDS via y2 


^ 




22 


SIP 


CoDS sends SIP 200 OK to CORE via y2 




N 


23 


SIP 


CORE sends SIP 200 OK to AS via ISC 




24 


SIP 


AS sends SIP 200 OK to CORE via ISC 


V 


25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


SIP 


UE sends SIP ACK to CORE via Gm 






27 


SIP 


CORE sends SIP ACK to AS via ISC 




28 


SIP 


AS sends SIP ACK to CORE via ISC 




29 


IGMP 


UE sends IGMP LEAVE to T&A via Dj 




30 


SIP 


CORE sends SIP ACK to CoDS via y2 






31 


















UE freezes the image of the broadcast TV 
channel 

























The RTSP DESCRIBE message in step 14 is sent in case the UE did not get content delivery description information 
(from the SSF or from the AS-IPTV/SS-MCF-IPTV during the SIP session initiation), 

It is acceptable to generate SIP UPDATE instead of re-INVITE requests. In that case SIP ACK requests should not be 
sent. 

There is no strict sequence of SIP and IGMP messages. The IGMP LEAVE message may be sent before or after 
sending SIP ACK. 
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4.4.4.2 Play in trick-play mode 



Interoperability Test Description 


Identifier: 


ID IMS IPTV BC2 0002 {S3A-0602) 


Summary: 


User requests the normal play mode on a broadcast TV channel in trick play mode 


References: 


TS 182 027 [1]; TS 183 063 [2], clause 7.2.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 




Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying frozen trick-play enabled broadcast TV channel 
(see TD_IMS_IPTV_BC2_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS 

• CoDS is recording the trick play enabled broadcast channel 


^^^^ ^^^ 


Test Sequence: 


Step 




1 


User requests to play the current paused broadcast TV channel in trick 
play mode 


2 


Verify that UE displays the recorded broadcast TV channel 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 














1 


















User requests to play the current paused 
broadcast TV channel in trick play mode 




2 












V 




RTSP 


UE sends RTSP PLAY (scale: +1) to CoDS via 
Xc 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 


















Verify that UE displays recorded broadcast TV 
channel 
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4.4.4.3 Simple fast forward trick-play 



Interoperability Test Description 


Identifier: 


ID IMS IPTV BC2 0003 {S3A-0602) 


Summary: 


User requests fast forward on a paused broadcast TV channel in trick play mode 
without reaching the end of recording 


References: 


TS 182 027 [11; TS 183 063 [2], clause 7.2.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying frozen trick-play enabled broadcast TV channel 
(see TD_IMS_IPTV_BC1_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and CoDS 

• CoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS 

• CoDS is recording the trick play enabled broadcast channel 




Test Sequence: 


Step 




1 


User requests x2 fast forward on the paused broadcast TV channel 


2 


Verify that UE displays recorded broadcast TV channel in fast forward 
mode 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


c 



D 
S 














1 




V 














User requests x2 fast forward on the paused 
broadcast TV channel 




2 












N. 




RTSP 


UE sends RTSP PLAY(scale -i-2) to CoDS via 
Xc 










3 






^ 










RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 




f 














UE displays recorded broadcast TV channel in 
fast forward mode 





















A RTSP PAUSE message may be sent between two consecutive RTSP PLAY messages. 
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4.4.4.4 Fast backward trick-play to beginning of recorded content 



Interoperability Test Description 


Identifier: 


ID IMS IPTV BC2 0004 {S3A-0702) 


Summary: 


User request a fast backward on a paused broadcast TV channel in trick play mode 


References: 


TS 182 027 [1]; TS 183 063 [2], clause 7.2.2 


Configuration: 


OF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 




Pre-test 
conditions: 


• UE, GoDS, Core IMS and IPTV AS are configured for method 2 

• User is registered in Gore IMS using userlPTV_priv identity 

• UE is displaying paused recorded broadcast TV channel 
(see TD_IMS_IPTV_BG2_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and GoDS 

• GoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS. 

• GoDS is recording the trick play enabled broadcast TV channel 


^^^^ ^^ 


Test Sequence: 


Step 




1 


User requests x2 fast backward on the paused broadcast TV channel 


2 


Verify that UE displays recorded broadcast TV channel in fast backward 
mode 


3 


Verify that UE stops display when beginning of recording is reached 






Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



1. Diagram 1 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 














1 


















User requests x2 fast backward on the paused 
broadcast TV channel 




2 












V 




RTSP 


UE sends RTSP PAUSE to GoDS via Xc 
(optional) 










3 
















RTSP 


GoDS sends RTSP 200 OK to UE via Xc 
(optional) 










4 
















RTSP 


UE sends RTSP PLAY(scale -2) to GoDS via Xc 










5 
















RTSP 


GoDS sends RTSP 200 OK to UE via Xc 










6 


















UE displays recorded broadcast TV channel in 
fast backward mode 


7 
















RTSP 


GoDS sends RTSP ANNOUNCE to UE via Xc 
(optional) 










8 












N. 




RTSP 


UE sends RTSP 200 OK to GoDS via Xc 
(optional) 










9 




d 














UE stops display when beginning of recording is 
reached 



In step 9, the UE is displaying a still image and then may switch to another mode. Handling of the start-of-stream in the 
ANNOUNCE message is up to the UE implementation. 
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4.4.4.5 Fast forward to move from trick-play to live broadcast mode 



Interoperability Test Description 


Identifier: 


ID IMS IPTV BC2 0005 {S3A-0802) 


Summary: 


User requests fast forward until the end of recording is reached and moves from trick 
play to live broadcast TV channel 


References: 


TS 182 027 [1], clause 8.3.6; TS 183 063 [2], clauses 5.1 .3.3.2, 7.2.2 and 8.1 .2.1 


Configuration: 


OF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS, TV HEAD END, T&A 


Pre-test 
conditions: 

L 


• UE, GoDS, Gore IMS and IPTV AS are configured for method 2 

• User is registered in Core IMS using userlPTV_priv identity 

• UE is displaying paused recorded broadcast TV channel 
(see TD_IMS_IPTV_BC2_0001) 

• EPG has at least one trick play enabled broadcast TV channel 

• T&A is configured with multicast rights for the UE 

• TV Head End broadcasting TV content in real-time using multicast 

• UE supports content protocols and coding used by TV Head End and GoDS 

• GoDS supports content protocols and coding used by TV Head End 

• User has trick-play rights in IPTV AS 

• GoDS is recording the trick play enabled broadcast TV channel 

• UE is configured to change to live broadcast automatically after trick play ends 


Test Sequence: 


Step 




1 


User requests x2 fast forward on a paused broadcast TV channel 


2 


Verify that UE displays recorded broadcast TV channel in fast forward 
mode 


3 


Verify that UE displays live broadcast TV channel when end of recording is 
reached 


^^H^V 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 


















User requests x2 fast forward on a paused broadcast TV 
channel 


^ 




2 
















RTSP 


UE sends RTSP PLAY (scale +2)to CoDS via Xc 


^ 








3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










4 


















UE displays recorded broadcast TV channel in fast forward 
mode 


5 






f 










RTSP 


CoDS sends RTSP ANNOUCE to UE via Xc 










6 


RTSP 


UE sends RTSP 200 OK to CoDS via Xc 










7 


IGMP 


UE sends IGMP JOIN to T&A via Dj 




8 


















UE displays live broadcast TV channel when end of 
recording is reached 


9 
















RTSP 


UE sends RTSP TEARDOWN to CoDS via Xc 


f 








10 


RTSP 


UE sends RTSP 200 OK to CoDS via Xc 




X 






11 


SIP 


UE sends SIP REINVITE to CORE via Gm 






12 


SIP 


CORE sends SIP REINVITE to AS via ISC 


^ 


13 


SIP 


AS sends SIP BYE to CORE via ISC 




14 
















SIP 


CORE sends SIP BYE to CoDS via y2 


^ 




15 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






16 


SIP 


CORE sends SIP 200 OK to AS via ISC 




17 


SIP 


AS sends SIP 200 OK to CORE via ISC 




18 


SIP 


CORE sends SIP 200 OK to UE via Gm 






19 


SIP 


UE sends SIP ACK to CORE via Gm 






20 


SIP 


CORE sends SIP ACK to AS via ISC 





















Upon receipt of the end-of-stream indication the CoDS sends in step 5 an RTSP ANNOUNCE to the UE with an 
indication that the end-of-stream has been reached. In case of BC sessions with trick-play, if the UE receives an RTSP 
ANNOUNCE request with an end-of-stream indication, the UE may initiate a session modification procedure in order 
to go back to a normal BC session in multicast mode (this is the case described above) or may alternatively take other 
actions (e.g. rewind, pause, terminate session, etc.). 

There is a delay between the UE receiving the RTSP ANNOUCE in step 4 and sending the RTSP TEARDOWN in step 
8 as well as SIP relNVITE in step 10. 

It is acceptable to generate SIP UPDATE instead of SIP relNVITE requests. In that case SIP ACK requests should not 
be sent. 

Before the RTSP PLAY message in step 2 a RTSP PAUSE message may be sent. 

There is no strict sequence of the SIP and IGMP messages. The IGMP JOIN message may be sent before or after 
sending the SIP ACK request. 
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4.4.5 Content on Demand (CoD) using Method 1 



4.4.5.1 Start CoD 



Interoperability Test Description | 


Identifier: 


ID IMS IPTV CoD1 0001 (S3A-1101) 


Summary: 


User requests to watch Content on Demand 


References: 


TS 182 027 [1], clause 8.4.1 ; TS 183 063 [2], clause 5.1.4.2 


Configuration: 


OF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


r~ 1 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE has received EPG from IPTV AS (see TD_ IMS_IPTV_ADS_000 1/2/3) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 




Test Sequence: 


Step 




1 


User requests to watch a CoD 


^^^^ 


Verify that UE displays the CoD 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 














1 




> 














User requests to watch a CoD 


2 










*. 


>. 




SIP 


UE sends SIP OPTION to CORE via Gm 


^ 




3 


SIP 


CORE sends SIP OPTION to AS via ISC 


^ 


4 


SIP 


AS sends SIP OPTION to CORE via ISC 




5 


SIP 


CORE sends SIP OPTION to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 




^. 


7 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP INVITE to CORE via Gm 






11 


SIP 


CORE sends SIP INVITE to AS via ISC 




12 


SIP 


AS sends SIP INVITE to CORE via ISC 




13 


SIP 


CORE sends SIP INVITE to CoDS via y2 


^ 




14 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






15 


SIP 


CORE sends SIP 200 OK to AS via ISC 




16 


SIP 


AS sends SIP 200 OK to CORE via ISC 


V 


17 


SIP 


CORE sends SIP 200 OK to UE via Gm 






18 


SIP 


UE sends SIP ACK to CORE via Gm 






19 


SIP 


CORE sends SIP ACK to AS via ISC 




20 


SIP 


AS sends SIP ACK to CORE via ISC 




21 


SIP 


CORE sends SIP ACK to CoDS via y2 






22 


RTSP 


UE sends RTSP PLAY to CoDS via Xc 


^ 








23 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










24 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional) 




>. 


25 


SIP 


CORE sends SIP INFO to AS via ISC (optional) 


^ 


26 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




27 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






28 




« 














UE displays the CoD 



The SIP OPTIONS message should be used for retrieving network parameters for the SDP payload in case that these 
parameters are not included in the SSF. 

When CoDS receives the very first RTSP PLAY message, the IPTV AS may send a SIP INFO message with 
CoDDeliveryStatus set to "Ongoing". 
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4.4.5.2 Pause CoD with trick-play 



Interoperability Test Description 


Identifier: 


ID IMS IPTV CoD1 0002 {S3A-1 201) 


Summary: 


User requests to pause a CoD using trick-play 


References: 


TS 182 027 [1]; TS 183 063 [2], clause 7.2.1 


Configuration: 


OF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Gore IMS, IPTV AS, CoDS 




Pre-test 
conditions: 


• UE, GoDS, Gore IMS and IPTV AS are configured for method 1 

• UE is registered in Gore IMS using userlPTV_priv identity 

• EPG has at least one GoD 

• UE is displaying a GoD 

(see TD_IMS_IPTV_GoD1_0001) 

• GoDS configured with GoD content 

• IMS GORE configured to forward GoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by GoDS 




Test Sequence: 

1 ^-^^^w^ m^^ 


Step 




1 


User requests to pause GoD 


2 


Verify that UE freezes the image of the CoD 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 




> 














User requests to pause GoD 


2 
















RTSP 


UE sends RTSP PAUSE to GoDS via Xc 










3 

4 


RTSP 


GoDS sends RTSP 200 OK to UE via Xc 
UE freezes the image of the GoD 















4.4.5.3 Play CoD in trick-play mode 



Interoperability Test Description 


Identifier: 


TD IMS IPTV GoDI 0003 (S3A-1 201) 


Summary: 


User requests play a GoD using trick-play 


References: 


TS 182 027 [1]; TS 183 063 [2], clause 7.2.1 


Configuration: 


GF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Gore IMS, IPTV AS, GoDS 


^^^^^^& 




Pre-test 
conditions: 


• UE, GoDS, Gore IMS and IPTV AS are configured for method 1 

• UE is registered in Gore IMS using userlPTV_priv identity 

• EPG has at least one GoD 

• UE is displaying paused GoD 
(see TD_IMS_IPTV_GoD1_0002) 

• GoDS configured with GoD content 

• IMS GORE configured to forward GoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by GoDS 


Test Sequence: 


Step 




1 


User requests to play the paused GoD 


2 


Verify that UE displays the GoD 


1 






Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 














1 




> 














User requests to play the paused CoD 


2 
















RTSP 


UE sends RTSP PLAY to CoDS via Xc 










3 

4 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
Verify tliat tlie UE displays the CoD 


«— 













4.4.5.4 Simple fast forward of CoD using trick-play 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD1 0004 (S3A-1 201) 


Summary: 


User requests fast forward on a paused CoD in trick play mode without reaching the 
end of recording 


References: 


TS 182 027 [1]; TS 183 063 [2], clause 7.2.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


1 




Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying paused CoD 
(see TD_IMS_IPTV_CoD1_0002) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


^ n 




Test Sequence: 


Step 




1 


User requests x2 fast forward on the paused CoD 


2 


Verify that UE displays images the CoD in fast forward mode 


I 


^^^^H 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 














1 


















User requests x2 fast forward on the paused 
CoD 




2 












V 




RTSP 


UE sends RTSP PAUSE to CoDS via Xc 
(optional) 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










4 


RTSP 


UE sends RTSP PLAY(scale +2) to CoDS via 
Xc 


' 








5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










6 




f 














UE displays images the CoD in fast forward 
mode 
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4.4.5.5 Simple fast backward on CoD using trick-play 



Interoperability Test Description 



Identifier: 



TD_IMS_IPTV_CoD1_0005 (S3A-1201) 



Summary: 



User requests fast backward on a paused CoD using trick play in trick play mode 
without reaching the beginning of the recording 



References: 



TS 182 027 [1]; TS 183 063 [2], clause 7.2.1 



Configuration: 



CF IMS IPTV 



Required 
Equipment: 



Pre-test 
conditions: 



IPTV aware UE, Core IMS, IPTV AS, CoDS 






UE, CoDS, Core IMS and IPTV AS are configured for method 1 

UE is registered in Core IMS using userlPTV_priv identity 

EPG has at least one CoD 

UE is displaying paused CoD 

(see TD_IMS_IPTV_CoD1_0002) 

CoDS configured with CoD content 

IMS CORE configured to forward CoD related SIP requests to AS IPTV 

UE supports content protocols and coding used by CoDS 



Test Sequence: 



Conformance 
Criteria: 



Step 



User requests x2 fast backward on the paused CoD 



Verify that UE displays images the CoD in fast backward mode 



Check 



fythatutd^playsmnagi 



1 [Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


c 

o 
D 
S 














1 


















User requests x2 fast backward on the paused 
CoD 




2 












>. 




RTSP 


UE sends RTSP PAUSE to CoDS via Xc 


^ 








3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 








N. 


4 


RTSP 


UE sends RTSP PLAY (scale -2) to CoDS via 
Xc 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










6 


















UE displays images the CoD in fast backward 
mode 
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4.4.5.6 Jump to specific location in CoD content 



Interoperability Test Description 



Identifier: 



TD_IMS_IPTV_CoD1_0006 (S3A-1201) 



Summary: 



User jumps to specific point in CoD using trick-play 



References: 



TS 182 027 [1]; TS 183 063 [2], clause 7.2.1 



Configuration: 



CF IIVIS IPTV 



Required 
Equipment: 

Pre-test 
conditions: 



IPTV aware UE, Core IMS, IPTV AS, CoDS 



UE, CoDS, Core IMS and IPTV AS are configured for method 1 

UE is registered in Core IMS using userlPTV_priv identity 

EPG has at least one CoD 

UE is displaying a CoD 

(see TD_IMS_IPTV_CoD1_0001) 

CoDS configured with CoD content 

IMS CORE configured to forward CoD related SIP requests to AS IPTV 

UE supports content protocols and coding used by CoDS 



Test Sequence: 



Conformance 
Criteria: 



Step 



User requests to jump to a specific location in the CoD 



Verify that UE displays the CoD from this specific point 



Check 



1 



pecmcpc 



Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


c 



D 
S 














1 


















User requests to jump to a specific location in 
the CoD 




2 












N. 




RTSP 


UE sends RTSP PAUSE to CoDS via Xc 


^ 








3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 








>. 


4 


RTSP 


UE sends RTSP PLAY (range=z) to CoDS via 
Xc 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










6 


















Verify that UE displays the CoD from this 
specific point 
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4.4.5.7 Quit watching CoD 



Interoperability Test Description 



Identifier: 



TD_IMS_IPTV_CoD1_0007 (S3A-1301) 



Summary: 



User quits watching CoD 



References: 



TS 182 027 [1], clause 8.4.3; TS 183 063 [2], clause 5.1.4.4.1 



Configuration: 



CF IMS IPTV 



Required 
Equipment: 

Pre-test 
conditions: 



IPTV aware UE, Core IMS, IPTV AS, CoDS 



UE, CoDS, Core IMS and IPTV AS are configured for method 1 

UE is registered in Core IMS using userlPTV_priv identity 

EPG has at least one CoD 

UE is displaying a CoD 

(see TD_IMS_IPTV_CoD1_0001) 

CoDS configured with CoD content 

IMS CORE configured to forward CoD related SIP requests to AS IPTV 

UE supports content protocols and coding used by CoDS 



Test Sequence: 



Conformance 
Criteria: 



Step 



User quits watching the CoD 



Verify that UE does not display the CoD anymore 



Cfieck 



day! 



1 [Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 




^ 














User quits watching the CoD 


2 








>. 


V 






SIP 


UE sends SIP INFO to CORE via Gm (optional) 


f 




3 


SIP 


CORE sends SIP INFO to AS via ISC (optional) 


^ 


4 


SIP 


AS sends SIP 200 OK to CORE via 
ISC(optional) 


N. 


5 


SIP 


CORE sends SIP 200 OK to UE via Gm 
(optional) 






6 


SIP 


UE sends SIP BYE to CORE via Gm 


f 




7 


SIP 


CORE sends SIP BYE to AS via ISC 


^ 


8 


SIP 


AS sends SIP BYE to CORE via ISC 




9 


SIP 


CORE sends SIP BYE to CoDS via y2 






10 


SIP 


CoDS sends SIP 200 OK to CORE via y2 


N. 




11 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


12 


SIP 


AS sends SIP 200 OK to CORE via ISC 




13 
14 


SIP 


CORE sends SIP 200 OK to UE via Gm 
UE does not display the CoD anymore 



















When a user requests to stop viewing a CoD with the intention of resuming it later, the UE may send a SIP INFO (with 
CoDOffset) request to the SCF. 
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4.4.5.8 Resume CoD 



Interoperability Test Description 


Identifier: 


ID IMS IPTV CoD1 0008 {S3A-1 401) 


Summary: 


User resumes a CoD from the last watching point 


References: 


TS 1 82 027 [1 ], clause 8.3.3; TS 1 83 063 [2], clauses 5.1 .3.4 and 8.1 .2.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 




Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• User has stopped watching a CoD prior to its end 
(see TD_IMS_IPTV_CoD1_0007) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


1 1 


Test Sequence: 
1 


Step 




1 


User requests to resume a CoD 


2 


Verify that UE displays the CoD from last watching point 


I 1 

Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 




^ 














User requests to resume a CoD 


2 








>. 


V 






SIP 


UE sends SIP OPTION to CORE via Gm 






3 


SIP 


CORE sends SIP OPTION to AS via ISC 




4 


SIP 


AS sends SIP OPTION to CORE via ISC 




5 


SIP 


CORE sends SIP OPTION to CoDS via y2 


^ 




6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 


V 




7 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


8 


SIP 


AS sends SIP 200 OK to CORE via ISC 


N. 


9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP INVITE to CORE via Gm 


^ 




11 


SIP 


CORE sends SIP INVITE to AS via ISC 


^ 


12 


SIP 


AS sends SIP INVITE to CORE via ISC 




13 


SIP 


CORE sends SIP INVITE to CoDS via y2 






14 


SIP 


CoDS sends SIP 200 OK to CORE via y2 




N. 


15 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


16 


SIP 


AS sends SIP 200 OK to CORE via ISC 




17 


SIP 


CORE sends SIP 200 OK to UE via Gm 






18 


SIP 


UE sends SIP ACK to CORE via Gm 






19 


SIP 


CORE sends SIP ACK to AS via ISC 




20 


SIP 


AS sends SIP ACK to CORE via ISC 




21 


SIP 


CORE sends SIP ACK to CoDS via y2 




V 


22 


RTSP 


UE sends RTSP PLAY to CoDS via Xc 










23 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










24 


SIP 


CoDS sends SIP INFO to CORE via y2 


N. 


V 


25 


SIP 


CORE sends SIP INFO to AS via ISC 


^ 


26 


SIP 


AS sends SIP 200 OK to CORE via ISC 




27 
28 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
UE displays the CoD from last watching point 
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The SIP OPTION message should be used for retrieving the network parameters for SDP when the parameters are not 
included in the SSF. 

The RTSP PLAY message shall carry the range parameter. The range parameter value may be retrieved from the SDP 
h-offset attribute in SIP procedure. Or, the range parameter value may be retrieved from SSF as the service action data 
value of CoDOffset which indicates the last stop point. 



4.4.5.9 CoD termination by IPTV AS 



Interoperability Test Description 



Identifier: 



TD_IMS_IPTV_CoD1_0009 (-) 



Summary: 



IPTV AS stops user from watching CoD 



References: 



TS 182 027 [1], clause 8.4.3; TS 183 063 [2], clause 5.1.4.4.1 



Configuration: 



CF IMS IPTV 



Required 
Equipment: 



Pre-test 
conditions: 



IPTV aware UE, Core IMS, IPTV AS, CoDS 



UE, CoDS, Core IMS and IPTV AS are configured for method 1 

UE is registered in Core IMS using userlPTV_priv identity 

EPG has at least one CoD 

UE is displaying a CoD 

(see TD_IMS_IPTV_CoD1_0001) 

CoDS configured with CoD content 

IPTV AS provides an interface that allows stopping of CoD provisioning 

IMS CORE configured to forward CoD related SIP requests to AS IPTV 

UE supports content protocols and coding used by CoDS 



Test Sequence: 



Step 



IPTV AS is requested to stop the CoD being watched by user 



Verify that UE stops displaying the CoD 



Conformance 
Criteria: 



Cfieck 



1 



Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 


















IPTV AS is requested to stop the CoD being 
watched by user 


2 










^ 






SIP 


AS sends SIP BYE to CORE via ISC (towards 
the CoDS) 




3 


SIP 


CORE sends SIP BYE to CoDS via y2 


^ 




4 


SIP 


CoDS sends SIP 200 OK to AS via y2 






5 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


6 


SIP 


AS sends SIP BYE to CORE via ISC (towards 
the UE) 




7 


SIP 


CORE sends SIP BYE to UE via Gm 






8 


SIP 


UE sends SIP 200 OK to CORE via Gm 






9 

10 


SIP 


CORE sends SIP 200 OK to AS via ISC 
UE stops displaying the CoD 


«— 
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4.4.5.10 EndofCoD 



Interoperability Test Description 


Identifier: 


ID IMS IPTV CoD1 0010 (-) 


Summary: 


User watches a CoD until its end 


References: 


TS 182 027 [1], clause 8.4.3; TS 183 063 [2], clause 5.1.4.4.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


^^^^^^^L ■.,,__,-..^ ^...^ J 


Pre-test 
conditions: 


• UE is registered in Gore IMS using userlPTV_priv identity 

• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD1_0001) 

• CoDS configured with (short) CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 




Test Sequence: 


Step 




1 


Verify that UE stops display at end of CoD 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














(1) 




« 














UE displays CoD 


2 






f 










RTSP 


CoDS sends RTSP ANNOUNCE (end-of-stream) to UE 
via Xc (optional) 










3 


SIP 


CoDS sends SIP INFO to CORE via ISC 
(optional, CoDDeliveryStatus = "Completed") 






4 


RTSP 


UE sends RTSP 200 OK to CoDS via Xc 
(optional) 










5 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional CoDDeliveryStatus = "Completed") 


^ 


6 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




7 
16 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
UE stops display at end of CoD 
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4.4.6 Video on Demand (CoD) using Metlnod 2 



4.4.6.1 Start CoD 



Interoperability Test Description 


Identifier: 


ID IMS IPTV CoD2 0001 (S3A-1102) 


Summary: 


User watches Video on Demand 


References: 


TS 182 027 [1], clause 8.4.1 ; TS 183 063 [2], clause 5.1.4.2 


Configuration: 


OF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


1— 1 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE has received EPG from IPTV AS (see TD_ IMS_IPTV_ADS_000 1/2/3) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


^^^ 


Test Sequence: 


Step 


1 


1 


User requests to watch a CoD 


2 


Verify that UE displays the CoD 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Three message flows are accepted for this TD. 
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1) With SIP re-INVITE messages for session modification: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 














1 




> 














User requests to watch a CoD 


2 










*. 






SIP 


UE sends SIP INVITE to CORE via Gm 


^ 




3 


SIP 


CORE sends SIP INVITE to AS via ISC 


^ 


4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 




^. 


7 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 


^ 


12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


RTSP 


UE sends RTSP DESCRIBE to CoDS via Xc 
(optional, only to get missing SDP parameters) 










15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










16 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 


^ 








17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 






V 




18 


SIP 


UE sends SIP relNVITE to CORE via Gm 






19 


SIP 


CORE sends SIP relNVITE to AS via ISC 




20 


SIP 


AS sends SIP relNVITE to CORE via ISC 




21 


SIP 


CORE sends SIP relNVITE to CoDS via y2 


^ 




22 


SIP 


CoDS sends SIP 200 OK to CORE via y2 


V 




23 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


24 


SIP 


AS sends SIP 200 OK to CORE via ISC 




25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


SIP 


UE sends SIP ACK to CORE via Gm 






27 










V 






SIP 


CORE sends SIP ACK to AS via ISC 


^ 


28 


SIP 


AS sends SIP ACK to CORE via ISC 




29 


SIP 


CORE sends SIP ACK to CoDS via y2 






30 


RTSP 


UE sends RTSP PLAY to CoDS via Xc 










31 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 






^ 




32 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional with user related IPTV service action 
data) 


V 




33 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




34 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




35 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






36 




i 














UE displays the CoD 
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2) With UPDATE SIP messages for session modification: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 














1 




> 














User requests to watch a CoD 


2 










*. 






SIP 


UE sends SIP INVITE to CORE via Gm 


^ 




3 


SIP 


CORE sends SIP INVITE to AS via ISC 


^ 


4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 




^. 


7 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 


^ 


12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


RTSP 


UE sends RTSP DESCRIBE to CoDS via Xc 
(optional, only to get missing SDP parameters) 










15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










16 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 


^ 








17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 






V 




18 


SIP 


UE sends SIP UPDATE to CORE via Gm 






19 


SIP 


CORE sends SIP UPDATE to AS via ISC 




20 


SIP 


AS sends SIP UPDATE to CORE via ISC 




21 


SIP 


CORE sends SIP UPDATE to CoDS via y2 


^ 




22 


SIP 


CoDS sends SIP 200 OK to CORE via y2 


V 




23 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


24 


SIP 


AS sends SIP 200 OK to CORE via ISC 




25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


RTSP 


UE sends RTSP PLAY to CoDS via Xc 


^ 








27 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










28 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional, with user related IPTV service action 
data) 






29 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




30 
















SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




31 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






32 




i 














UE displays the CoD 
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3) With RTSP Channel establishing without session modification: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 






1 




J 














User rGQuests to watch a CoD 


2 










N. 






SIP 


UE sends SIP INVITE to CORE via Gm 


^ 




3 


SIP 


CORE sends SIP INVITE to AS via ISC 


^ 


4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 




N. 


7 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 


^ 


12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 




V 


14 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 










15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










16 


RTSP 


UE sends RTSP PLAY to CoDS via Xc 


^ 








17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










18 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional with user related IPTV service action 
data) 


V 




19 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




20 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




21 
22 


SIP 


CORE sends SIP 200 OK to CoDS via y2 

(optional) 

UE displays the CoD 


«— 

















4.4.6.2 Pause CoD with trick-play 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD2 0002 (S3A-1 201) 


Summary: 


User pauses a CoD using trick-play 


References: 


TS 182 027 [1], clause 8.4.1 ; TS 183 063 [2], clause 5.1.4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


i 1 




Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD2_0001) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 




Test Sequence: 


Step 




1 


User requests to pause CoD 


2 


Verify that UE freezes the image of the CoD 






Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


c 

o 
D 
S 














1 




^ 














User requests to pause CoD 


2 




i 








N. 




RTSP 


UE sends RTSP PAUSE to CoDS via Xc 


f 








3 
4 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
UE freezes the image of the CoD 











4.4.6.3 Play CoD with trick-play 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD2 0003 (S3A-1 201) 


Summary: 


User plays a CoD using tricl<-play 


References: 


TS 182 027 [1], clause 8.4.1 ; TS 183 063 [2], clause 5.1.4.2 


Configuration: 


CF IMS IPTV 


Required 

Equipment: 

1 ^ 


IPTV aware UE, Core IMS, IPTV AS, CoDS 




1 

Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is in pause mode watching a CoD 
(see TD_IMS_IPTV_CoD2_0002) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


J 


Test Sequence: 


Step 




1 


User requests to play the paused CoD 


2 


Verify that UE displays the CoD 


^" 




1 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 






1 




J 














User reauests to olav the caused CoD 


2 




k 












RTSP 


UE sends RTSP PLAY to CoDS via Xc 


^ 








3 

4 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
Verify that the UE displays the CoD 
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4.4.6.4 Fast forward CoD using trick-play 



Interoperability Test Description 



Identifier: 



TD_IMS_IPTV_CoD2_0004 (S3A-1202) 



Summary: 



User fast forwards CoD using trick play 



References: 



TS 182 027 [1], clause 8.4.1 ; TS 183 063 [2], clause 5.1.4.2 



Configuration: 



OF IMS IPTV 



Required 
Equipment: 

Pre-test 
conditions: 



IPTV aware UE, Core IMS, IPTV AS, CoDS 



UE, CoDS, Core IMS and IPTV AS are configured for method 2 

UE is registered in Core IMS using userlPTV_priv identity 

EPG has at least one CoD 

UE is displaying a CoD 

(see TD_IMS_IPTV_CoD2_0003) 

CoDS configured with CoD content 

IMS CORE configured to forward CoD related SIP requests to AS IPTV 

UE supports content protocols and coding used by CoDS 



Test Sequence: 



Jiilliillt 



Conformance 
Criteria: 



Step 



User requests to x2 fast forward CoD 



Verify that UE displays images the CoD in fast forward mode 



i. 



Cfieck 



1 



Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 




» 














User requests to fast forward CoD 


2 












N. 




RTSP 


UE sends RTSP PAUSE to CoDS via Xc 
(optional) 


^ 








3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 








V 


4 


RTSP 


UE sends RTSP PLAY(scale +2) to CoDS via 
Xc 


^ 








5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










6 




^ 














UE displays images the CoD in fast forward 
mode 

















The UE may send a RTSP PAUSE before sending RTSP PLAY. 
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4.4.6.5 Fast backward CoD using trick-play 



Interoperability Test Description 


Identifier: 


ID IMS IPTV CoD2 0005 (S3A-1 202) 


Summary: 


User fast backwards CoD using trick play 


References: 


TS 182 027 [1], clause 8.4.1 ; TS 183 063 [2], clause 5.1.4.2 


Configuration: 


OF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Gore IMS, IPTV AS, CoDS 




Pre-test 
conditions: 


• UE, GoDS, Gore IMS and IPTV AS are configured for method 2 

• UE is registered in Gore IMS using userlPTV_priv identity 

• EPG has at least one GoD 

• UE is displaying a GoD 

(see TD_IMS_IPTV_GoD2_0003) 

• GoDS configured with GoD content 

• IMS GORE configured to forward GoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by GoDS 


1 1 


Test Sequence: 


Step 




1 


User requests to x2 fast backward GoD 


2 


Verify that UE displays images the GoD in fast backward mode 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


c 



D 
S 














1 




^ 














User requests to fast backward GoD 


2 
















RTSP 


UE sends RTSP PAUSE to GoDS via Xc 
(optional) 










3 


RTSP 


GoDS sends RTSP 200 OK to UE via Xc 
(optional) 








N. 


4 


RTSP 


UE sends RTSP PLAY (scale -2) to GoDS via 
Xc 










5 


RTSP 


GoDS sends RTSP 200 OK to UE via Xc 










6 


















Verify that UE displays images the GoD in fast 
backward mode 

















The UE may send a RTSP PAUSE before sending RTSP PLAY. 
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4.4.6.6 Jump to specific location in CoD content 



Interoperability Test Description 



Identifier: 



TD_IMS_IPTV_CoD2_0006 (S3A-1202) 



Summary: 



User jumps in CoD to specific point using trick-play 



References: 



TS 182 027 [1], clause 8.4.1 ; TS 183 063 [2], clause 5.1.4.2 



Configuration: 



CF IMS IPTV 



Required 
Equipment: 

Pre-test 
conditions: 



IPTV aware UE, Core IMS, IPTV AS, CoDS 



UE, CoDS, Core IMS and IPTV AS are configured for method 2 

UE is registered in Core IMS using userlPTV_priv identity 

EPG has at least one CoD 

UE is displaying a CoD 

(see TD_IMS_IPTV_CoD2_0002) 

CoDS configured with CoD content 

IMS CORE configured to forward CoD related SIP requests to AS IPTV 

UE supports content protocols and coding used by CoDS 



Test Sequence: 



Conformance 
Criteria: 



Step 



User requests to jump to a specific location in the CoD 



Verify that UE displays the CoD from this specific point 



Cfieck 



1 



pecmcpc 



Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














1 


















User requests to jump to a specific location in 
the CoD 




2 
















RTSP 


UE sends RTSP PAUSE to CoDS via Xc 
(optional) 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










4 


RTSP 


UE sends RTSP PLAY (range=z) to CoDS via 
Xc 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










6 


















Verify that UE displays the CoD from this 
specific point 

















The UE may send a RTSP PAUSE before sending RTSP PLAY. 
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4.4.6.7 Terminate CoD 



Interoperability Test Description 


Identifier: 


ID IMS IPTV CoD2 0007 {S3A-1 302) 


Summary: 


User quits watching CoD 


References: 


TS 182 027 [1], clause 8.4.1 ; TS 183 063 [2], clause 5.1.4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 




Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD2_0003) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


1 1 


Test Sequence: 
1 


Step 




1 


User quits watching the CoD 


2 


Verify that the UE does not display the CoD anymore 


1 ^^^^^ 

Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Two message flows are accepted for this TD. 

1) With SIP messages exchange initiated by UE: 



Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 






D 
S 














1 




» 














User quits watching the CoD 


2 












V 




SIP 


UE sends SIP INFO to CORE via Gm 


f 




3 


SIP 


CORE sends SIP INFO to AS via ISC 


^ 


4 


SIP 


AS sends SIP 200 OK to CORE via ISC 




5 


SIP 


CORE sends SIP 200 OK to UE via Gm 






6 


RTSP 


UE sends RTSP TEARDOWN to CoDS via Xc 










7 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 






N. 




8 


SIP 


UE sends SIP BYE to CORE via Gm 


f 




9 


SIP 


CORE sends SIP BYE to AS via ISC 


^ 


10 


SIP 


AS sends SIP BYE to CORE via ISC 




11 


SIP 


CORE sends SIP BYE to CoDS via y2 






12 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






13 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


14 


SIP 


AS sends SIP 200 OK to CORE via ISC 




15 
16 


SIP 


CORE sends SIP 200 OK to UE via Gm 
UE does not display the CoD anymore 
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2) With SIP messages exchange initiated by CoDS: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


c 

o 
D 
S 














1 


















User quits watching the CoD 




2 
















RTSP 


UE sends RTSP PAUSE to CoDS via Xc 
(optional) 










3 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 








■N. 


4 


RTSP 


UE sends RTSP TEARDOWN to MVS via Xc 


^ 




^ 




5 


SIP 


CoDS sends SIP INFO (with CoDOffset) to 
CORE via y2 (optional) 


N. 


■N. 


6 


SIP 


CORE sends SIP INFO to AS via ISC 


^ 


7 


SIP 


AS sends SIP 200 OK to CORE via ISC 




8 


SIP 


CORE sends SIP 200 OK to CoDS via y2 






9 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










10 


SIP 


UE sends SIP BYE to CORE via Gm 






11 


SIP 


CORE sends SIP BYE to AS via ISC 




12 


SIP 


AS sends SIP BYE to CORE via ISC 




13 


SIP 


CORE sends SIP BYE to CoDS via y2 






14 


SIP 


CoDS sends SIP 200 OK to CORE via y2 






15 


SIP 


CORE sends SIP 200 OK to AS via ISC 




16 


SIP 


AS sends SIP 200 OK to CORE via ISC 




17 


SIP 


CORE sends SIP 200 OK to UE via Gm 






18 




i 














UE does not display the CoD anymore 
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4.4.6.8 Resume CoD 



Interoperability Test Description 


Identifier: 


ID IMS IPTV CoD2 0008 {S3A-1 402) 


Summary: 


User resumes a CoD from the last watching point 


References: 


TS 182 027 [1], clause 8.4.1 ; TS 183 063 [2], clause 5.1.4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 




Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• User has stopped watching a program prior to its end 
(see TD_IMS_IPTV_CoD2_0006) 

• CoDS configured with CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 




Test Sequence: 

1 „ ^ 


Step 




1 


User requests to resume a CoD 


2 


Verify that UE displays the CoD from last watching point 


1 ^^^^^ 

Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Three message flows are accepted for this TD. 
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1) Using SIP re-INVITE messages for session modification: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 














1 




> 














User requests to resume a CoD 


2 










*. 






SIP 


UE sends SIP INVITE to CORE via Gm 


^ 




3 


SIP 


CORE sends SIP INVITE to AS via ISC 


y 


4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 




^. 


7 


SIP 


CORE sends SIP 200 OK to AS via ISC 


y 


8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 


y 


12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


RTSP 


UE sends RTSP DESCRIBE to CoDS via Xc 
(optional, only to get missing SDP parameters) 


^ 








15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










16 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 










17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 




v 


V 




18 


SIP 


UE sends SIP relNVITE to CORE via Gm 






19 


SIP 


CORE sends SIP relNVITE to AS via ISC 




20 


SIP 


AS sends SIP relNVITE to CORE via ISC 




21 


SIP 


CORE sends SIP relNVITE to CoDS via y2 


y 




22 


SIP 


CoDS sends SIP 200 OK to CORE via y2 


N. 




23 


SIP 


CORE sends SIP 200 OK to AS via ISC 


y 


24 


SIP 


AS sends SIP 200 OK to CORE via ISC 


*. 


25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


SIP 


UE sends SIP ACK to CORE via Gm 






27 


SIP 


CORE sends SIP ACK to AS via ISC 




28 










y 


>. 




SIP 


AS sends SIP ACK to CORE via ISC 




29 


SIP 


CORE sends SIP ACK to CoDS via y2 




■N. 


30 


RTSP 


UE sends RTSP PLAY (with range parameter) 
to CoDS via Xc 










31 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










32 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional) 




■N. 


33 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




34 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




35 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






36 




i 














UE displays the CoD from last watching point 



Note that the range parameter value in step 30 may be retrieved from the SDP h-offset attribute in SIP procedure. Or, 
the range parameter value may be retrieved from SSF as the service action data value of CoDOffset which indicates the 
last stop point. 
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2) Using SIP UPDATE messages for session modification: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 














1 




> 














User requests to resume a CoD 


2 










*. 






SIP 


UE sends SIP INVITE to CORE via Gm 


^ 




3 


SIP 


CORE sends SIP INVITE to AS via ISC 


^ 


4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 




^. 


7 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 


^ 


12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 






14 


RTSP 


UE sends RTSP DESCRIBE to CoDS via Xc 
(optional, only to get missing SDP parameters) 


^ 








15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 










16 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 










17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 






V 




18 


SIP 


UE sends SIP UPDATE to CORE via Gm 






19 


SIP 


CORE sends SIP UPDATE to AS via ISC 




20 


SIP 


AS sends SIP UPDATE to CORE via ISC 




21 


SIP 


CORE sends SIP UPDATE to CoDS via y2 


^ 




22 


SIP 


CoDS sends SIP 200 OK to CORE via y2 


N. 


>. 


23 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


24 


SIP 


AS sends SIP 200 OK to CORE via ISC 




25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


RTSP 


UE sends RTSP PLAY (range parameter) to 
CoDS via Xc 


^ 








27 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










28 
















SIP 


CoDS sends SIP INFO to CORE via y2 
(optional) 




>. 


29 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 


^ 


30 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




31 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






32 




i 














UE displays the CoD from last watching point 



Note that the range parameter value in step 26 may be retrieved from the SDP h-offset attribute in SIP procedure. Or, 
the range parameter value may be retrieved from SSF as the service action data value of CoDOffset which indicates the 
last stop point. 
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3) Using RTSP channel establishment without session modification: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 














1 




> 














User requests to resume a CoD 


2 










*. 






SIP 


UE sends SIP INVITE to CORE via Gm 


^ 




3 


SIP 


CORE sends SIP INVITE to AS via ISC 


^ 


4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to CoDS via y2 






6 


SIP 


CoDS sends SIP 200 OK to CORE via y2 




^. 


7 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 


^ 


12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to CoDS via y2 




>. 


14 


RTSP 


UE sends RTSP SETUP to CoDS via Xc 










15 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 








>. 


16 


RTSP 


UE sends RTSP PLAY(with range parameter) to 
CoDS via Xc 


^ 








17 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










18 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional) 




N. 


19 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 


^ 


20 


SIP 


AS sends SIP 200 OK to CORE via ISC 

(optional) 




21 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






22 




i 














UE displays the CoD from last watching point 



The range parameter value in step 16 may be retrieved from the SDP h-offset attribute in SIP procedure. Or, the range 
parameter value may be retrieved from SSF as the service action data value of CoDOffset which indicates the last stop 
point. 
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4.4.6.9 CoD termination by IPTV AS 



Interoperability Test Description 


Identifier: 


ID IMS IPTV CoD2 0009 (S3A-1 402) 


Summary: 


AS IPTV stops user from watching CoD 


References: 


TS 182 027 [1], clause 8.4.1 ; TS 183 063 [2], clause 5.1.4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


^^^^^^K 




J 


Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD2_0001 ) 

• CoDS configured with CoD content 

• IPTV AS provides an interface that allows stopping of CoD provisioning 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


1 


Test Sequence: 


Step 




1 


IPTV AS is requested to stop ongoing CoD 


2 


Verify that UE stops displaying the CoD 


1 




1 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 

s 


C 
o 
D 
S 














1 


















IPTV AS is requested to stop ongoing CoD 


2 










^ 


V 




SIP 


AS sends SIP BYE to CORE via ISC 




3 


SIP 


CORE sends SIP BYE to UE via Gm 






4 


RTSP 


UE sends RTSP PAUSE to CoDS via Xc 
(optional) 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
(optional) 








N. 


6 


RTSP 


UE sends RTSP TEARDOWN to CoDS via Xc 


^ 








7 


SIP 


CoDS sends SIP INFO to CORE via y2 
(optional with CoDOffset) 


N. 


V 


8 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 


^ 


9 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




10 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
(optional) 






11 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 






V 




12 


SIP 


UE sends SIP 200 OK to CORE via Gm 






13 


SIP 


CORE sends SIP 200 OK to AS via ISC 




14 


SIP 


AS sends SIP BYE to CORE via ISC 




15 


SIP 


CORE sends SIP BYE to CoDS via y2 


^ 




16 


SIP 


CoDS sends SIP 200 OK to CORE via y2 


V 




17 
18 


SIP 


CORE sends SIP 200 OK to AS via ISC 
UE stops displaying the CoD 
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4.4.6.1 CoD termination at the end of stream 



Interoperability Test Description 


Identifier: 


TD IMS IPTV CoD2 00010 {S3A-1 701) 


Summary: 


User watches a CoD until its end 


References: 


TS 182 027 [1], clause 8.4.1 ; TS 183 063 [2], clause 5.1.4.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 




Pre-test 
conditions: 


• UE, CoDS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• EPG has at least one CoD 

• UE is displaying a CoD 

(see TD_IMS_IPTV_CoD2_0001 ) 

• CoDS configured with (short) CoD content 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• UE supports content protocols and coding used by CoDS 


1 1 


Test Sequence: 


Step 




1 


Verify that the UE stops at end of CoD 




^^^^^^^^ 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Two message flows are accepted for this TD. 

1) Using SIP INFO and RTSP ANNOUNCE messages: 



Step 


Direction 


Protocol 


Comment 




U 

s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 



D 
S 














(1) 




« 














UE displays CoD 


2 
















RTSP 


CoDS sends RTSP ANNOUNCE (end-of-stream) to UE 
viaXc 










3 


SIP 


CoDS sends SIP INFO to CORE via ISC 
(optional, CoDDeliveryStatus = "Completed") 






4 


RTSP 


UE sends RTSP 200 OK to CoDS via Xc 
(optional) 










5 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional CoDDeliveryStatus = "Completed") 


^ 


6 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




7 


SIP 


CORE sends SIP 200 OK to CoDS via y2 






8 


SIP 


UE sends SIP INFO to CORE via Gm 
(optional) 


^ 




9 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




10 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




11 
12 


SIP 


CORE sends SIP 200 OK to UE via Gm 

(optional) 

UE stops CoD 
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2) With SIP INFO messages on receiving RTSP TEARDOWN: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


c 



D 
S 






(1) 




^ 














UE disDiavs CoD 


2 






^ 










RTSP 


CoDS sends RTSP ANNOUNCE (end-of-stream) to UE 
viaXc 








N. 


3 


RTSP 


UE sends RTSP 200 OK to CoDS via Xc 








V 


4 


RTSP 


UE sends RTSP PAUSE to CoDS via Xc (optional) 










5 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc (optional) 






^ 




7 


SIP 


CoDS sends SIP INFO to CORE via ISC 
(optional, CoDDeliveryStatus = "Completed") 




N. 


8 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional CoDDeliveryStatus = "Completed") 




9 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




10 
11 


SIP 


CORE sends SIP 200 OK to CoDS via y2 
UE stops CoD 


«— 

















4.4.7 



NPVR using Method 1 



4.4.7.1 liTipulsive recording request 



Interoperability Test Description 


Identifier: 


TD IMS IPTV nP1 0001 (S3A-1901) 


Summary: 


User requests an impulsive recording of a broadcast TV channel 


References: 


TS 182 027 [1], clause 8.5; TS 183 063 [2] 


Configuration: 


CF IMS IPTV 


Required Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV Head End, T&A, PVRS 


^^ 


Pre-test conditions: 


• UE, PVRS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTVpriv identity 

• UE supports nPVR 

• EPG has at least one nPVR enabled broadcast TV channel 

• UE is displaying broadcast TV channel 
(see TD_IMS_IPTV_BC_0001 ) 

• User has nPVR rights in IPTV AS 

• IMS CORE configured to forward nPVR related SIP requests to 
AS IPTV 

• UE, PVRS and TV Head End support the same content protocols 
and coding 




Test Sequence: 


Step 




1 


User requests an impulsive 
recording of a broadcast TV 
channel 


2 


Verify that UE confirms recording 


3 


User requests EPG after the end 
of the recorded program 


4 


Verify that UE displays EPG with 
the new entry 


Conformance Criteria: 


Check 




1 


Message exchange follows the 
below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


P 
V 
R 
S 














1 


















User requests an impulsive recording of a 
broadcast TV channel 




2 










V 






SIP 


UE sends SIP MESSAGE (bookmark) to GORE 
viaGm 


f 




3 


SIP 


CORE sends SIP MESSAGE (bookmark) to AS 
via ISC 


^ 


4 


SIP 


AS sends SIP 200 OK to GORE via ISC 




5 


SIP 


CORE sends SIP 200 OK to UE via Gm 






1 










^ 






SIP 


AS sends SIP to CORE via ISC immediately 
(not described in R2) 




i 


SIP 


CORE sends SIP to PVRS via y2 
(not described in R2) 






1 
















IGMPJoin 


PVRS starts recording TV Channel program 
(not described in R2) 








i 


IGMP Leave 


PVRS stops recording TV Channel program at 
the end of the program 
(not described in R2) 








7 










^ 






SIP 


AS sends SIP MESSAGE to CORE via ISC 
(optional may exist prior to IGMP join) 




8 


SIP 


CORE sends SIP MESSAGE to UE via Gm 
(optional may exist prior to IGMP join) 






9 


SIP 


UE sends SIP 200 OK to CORE via Gm 
(optional may exist prior to IGMP join) 






10 


SIP 


CORE sends SIP 200 OK to AS via ISC 
(optional may exist prior to IGMP join) 




11 


















User requests EPG after the end of the 
recorded program 




12 
















HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 


f 






13 
14 


HTTP 


AS sends HTTP 200 OK to UE via Xa (1 to n 

times) 

UE displays EPG with the new entry 

















Steps tagged "i" do not follow a given specification. They are here for information and show the simple message 
exchange that could happen between the NPVR, TA, CORE and AS nodes in this case. 

Steps 1 1 and 12 allows UE to get TV content captured in steps "i" as described in clause 8.5.2 of [1]. 
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4.4.7.2 Scheduled recording request 



Interoperability Test Description 


Identifier: 


ID IMS IPTV nP1 0002(S3A-2001) 


Summary: 


User requests a scheduled recording of a broadcast TV channel 


References: 


TS 1 82 027 [1 ], clause 8.5; TS 1 83 063 [2] 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV Head End, T&A, PVRS 


^^^^ 


Pre-test 
conditions: 

1 


• UE is registered in Core IMS and received EPG from IPTV AS 
(see TD_ IMS_IPTV_ADS_0001/2/3) 

• UE, PVRS, Core IMS and IPTV AS are configured for method 1 

• UE is registered in Core IMS using userlPTV_priv identity 

• UE supports nPVR 

• EPG has at least one nPVR enabled broadcast TV channel 

• UE is not displaying broadcast TV channel 

• User has nPVR rights in IPTV AS 

• IMS CORE configured to forward nPVR related SIP requests to AS IPTV 

• UE, PVRS and TV Head End support the same content protocols and coding 


Test Sequence: 


Step 




1 


User requests a scheduled recording of a broadcast TV channel 


2 


Verify that UE confirms parking 


3 


User requests EPG after the end of the recorded program 


4 


Verify that UE displays EPG with the new entry 


^ 


Conformance 
Criteria: 


Check 


- :■ 


1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


c 


R 

E 


A 
S 


P 
V 
R 
S 














1 


















User requests a scheduled recording of a 
broadcast TV channel 




2 








N. 


V 






SIP 


UE sends SIP MESSAGE to GORE via Gm 






3 


SIP 


GORE sends SIP MESSAGE to AS via ISC 




4 


SIP 


AS sends SIP 200 OK to GORE via ISG 




5 


SIP 


GORE sends SIP 200 OK to UE via Gm 






1 








^ 




V 




SIP 


AS sends SIP to CORE via ISC 
(not described in R2) 




i 


SIP 


CORE sends SIP to PVRS via y2 
(not described in R2) 






1 


IGMPJoin 


PVRS starts recording TV Channel program, at 

"start-time" 

(not described in R2) 








i 


IGMP Leave 


PVRS stops recording TV Channel program at 

"end-time" 

(not described in R2) 








7 










^ 






SIP 


AS sends SIP MESSAGE to CORE via ISC 
(optional may exist prior to IGMP join) 




8 


SIP 


CORE sends SIP MESSAGE to UE via Gm 
(optional may exist prior to IGMP join) 






9 


SIP 


UE sends SIP 200 OK to CORE via Gm 
(optional may exist prior to IGMP join) 






10 


SIP 


CORE sends SIP 200 OK to AS via ISC 
(optional may exist prior to IGMP join) 




11 


















User requests EPG after the end of the 
recorded program 




12 
















HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 








13 


HTTP 


AS sends HTTP 200 OK to UE via Xa (1 to n 
times) 








14 




























UE displays EPG with the new entry 



Steps tagged "i" do not follow a given specification. They are here for information and show the simple message 
exchange that could happen between the NPVR, TA, CORE and AS nodes in this case. 
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4.4.7.3 Watching a recorded nPVR content 



Interoperability Test Description 


Identifier: 


ID IMS IPTV nP1 0003(S3A-2201) 


Summary: 


User watches a recorded content 


References: 


TS 1 82 027 [1 ], clause 8.5; TS 1 83 063 [2] 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, PVRS 


^ .„, J 


Pre-test 
conditions: 


• UE, PVRS, Gore IMS and IPTV AS are configured for method 1 

• UE is registered in Gore IMS using userlPTV_priv identity 

• UE supports nPVR 

• EPG has at least one nPVR enabled broadcast TV channel 

• nPVR content is available in PVRS based on either an impulsive or scheduled 
request to capture broadcast TV channel (see TD_IMS_IPTV_nP1_0001/2) 

• User has nPVR rights in IPTV AS 

• IMS GORE configured to forward nPVR related SIP requests to AS IPTV 

• UE, PVRS and TV Head End support the same content protocols and coding 


Test Sequence: 


Step 






1 


User requests to watch recorded content 




2 


Verify that UE displays recorded content 


1 1 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


P 

V 
R 
S 














1 




> 














User requests to watch recorded content 


2 










V 






SIP 


UE sends SIP OPTION to CORE via Gm 

(to retrieve parameters to build SDP - optional) 


^ 




3 


SIP 


CORE sends SIP OPTION to AS via ISC 
(optional) 




4 


SIP 


AS sends SIP OPTION to CORE via ISC 
(optional) 




5 


SIP 


CORE sends SIP OPTION to PVRS via y2 

(optional) 






6 


SIP 


PVRS sends SIP 200 OK to CORE via y2 
(optional) 


N. 




7 


SIP 


CORE sends SIP 200 OK to AS via ISC 
(optional) 


^ 


8 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 


V 


9 


SIP 


CORE sends SIP 200 OK to UE via Gm 
(optional) 






10 


SIP 


UE sends SIP INVITE to CORE via Gm 






11 


SIP 


CORE sends SIP INVITE to AS via ISC 




12 


SIP 


AS sends SIP INVITE to CORE via ISC 




13 


SIP 


CORE sends SIP INVITE to PVRS via y2 






14 


SIP 


PVRS sends SIP 200 OK to CORE via y2 


N. 


>. 


15 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


16 


SIP 


AS sends SIP 200 OK to CORE via ISC 




17 


SIP 


CORE sends SIP 200 OK to UE via Gm 






18 


SIP 


UE sends SIP ACK to CORE via Gm 






19 


SIP 


CORE sends SIP ACK to AS via ISC 


^ 


20 


SIP 


AS sends SIP ACK to CORE via ISC 




21 


SIP 


CORE sends SIP ACK to PVRS via y2 






22 


RTSP 


UE sends RTSP PLAY to PVRS via Xc 










23 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 










24 
















SIP 


PVRS sends SIP INFO to CORE via y2 
(optional) 


N. 


■N. 


25 


SIP 


CORE sends SIP INFO to AS via ISC (optional) 




26 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




27 


SIP 


CORE sends SIP 200 OK to PVRS via y2 
(optional) 






28 




« 














UE displays the recorded content 
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4.4.8 NPVR - Method 2 



4.4.8.1 Impulsive recording request 



Interoperability Test Description 


Identifier: 


ID IMS IPTV nP2 0001 (S3A-1902) 


Summary: 


User requests to park and pickup a broadcast TV channel 


References: 


TS 1 82 027 [1 ], clause 8.5; TS 1 83 063 [2] 


Configuration: 


CF IMS IPTV 


Required Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV Head End, T&A, PVRS 


1 . 

Pre-test conditions: 


• UE, PVRS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• UE supports nPVR 

• EPG has at least one nPVR enabled broadcast TV channel 

• UE is displaying broadcast TV channel 
(see TD_IMS_IPTV_BC_0001) 

• User has nPVR rights in IPTV AS 

• IMS CORE configured to forward nPVR related SIP requests to 
AS IPTV 

• UE, PVRS and TV Head End support the same content protocols 
and coding 


1 —I 


Test Sequence: 


Step 




1 


User requests an impulsive recording of a broadcast TV 
channel 


2 


Verify that UE confirms recording 


3 


User requests EPG after the end of the recorded program 


4 


Verify that UE displays EPG with new entry 


1 




J 


Conformance Criteria: 


Check 




1 


Message exchange follows the below table 
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The message flow is divided into two phases. The first one corresponding to the park request is given below: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


P 
V 
R 
S 














1 


















User requests an impulsive recording of a 
broadcast TV Channel 




2 




^ 






"V 






SIP 


UE sends SIP MESSAGE to CORE via Gm 






3 


SIP 


CORE sends SIP MESSAGE to AS via ISC 


y 


4 


SIP 


AS sends SIP 200 OK to CORE via ISC 




5 
6 


SIP 


CORE sends SIP 200 OK to UE via Gm 
UE confirms parking 






















SIP 


AS sends SIP to CORE via ISC immediately 
(not described in R2) 




















SIP 


CORE sends SIP to PVRS via y2 
(not described in R2) 








IGMP Join 


PVRS starts recording TV Channel program 
(not described in R2) 








i 


IGMP Leave 


PVRS stops recording TV Channel program at 
the end of the program 
(not described in R2) 








7 
















SIP 


AS sends SIP MESSAGE to CORE via ISC 
(optional may exist prior to IGMP join) 


>. 


8 


SIP 


CORE sends SIP MESSAGE to UE via Gm 
(optional may exist prior to IGMP join) 






9 


SIP 


UE sends SIP 200 OK to CORE via Gm 
(optional may exist prior to IGMP join) 






10 


SIP 


CORE sends SIP 200 OK to AS via ISC 
(optional may exist prior to IGMP join) 




11 


















User requests EPG after the end time of 
program 




12 
















HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 








13 


HTTP 


AS sends HTTP 200 OK to UE via Xa (1 to n 
times) 








14 




^ 
























UE displays EPG with new entry 



Steps tagged "i" do not follow a given specification. They are here for information and show the simple message 
exchange that could happen between the NPVR, TA, CORE and AS nodes in this case. 
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4.4.8.2 Scheduled recording request 



Interoperability Test Description 


Identifier: 


TD IMS IPTV nP2 0002 (S3A-2102) 


Summary: 


User requests the scheduled recording of a broadcast TV channel 


References: 


TS 1 82 027 [1 ], clause 8.5; TS 1 83 063 [2] 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, TV Head End, T&A, PVRS 


^^^^ 


Pre-test 
conditions: 

1 


• UE is registered in Core IMS and received EPG from IPTV AS 
(see TD_ IMS_IPTV_ADS_0001/2/3) 

• UE, PVRS, Core IMS and IPTV AS are configured for method 2 

• UE is registered in Core IMS using userlPTV_priv identity 

• UE supports nPVR 

• EPG has at least one nPVR enabled broadcast TV channel 

• UE is not displaying broadcast TV channel 

• User has nPVR rights in IPTV AS 

• IMS CORE configured to forward nPVR related SIP requests to AS IPTV 

• UE, PVRS and TV Head End support the same content protocols and coding 


Test Sequence: 


Step 




1 


User requests the scheduled recording of a broadcast TV channel 


2 


Verify that UE confirms recording 


3 


User requests EPG after the end of the recorded program 


4 


Verify that UE displays EPG with new entry 


^ 


Conformance 
Criteria: 


Check 


- :■ 


1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


p 

V 
R 
S 














1 


















User requests the scheduled recording of a 
broadcast TV channel 




2 




( 












SIP 


UE sends SIP MESSAGE to GORE via Gm 


^ 




3 


SIP 


CORE sends SIP MESSAGE to AS via ISC 


^ 


4 


SIP 


AS sends SIP 200 OK to GORE via ISC 




5 


SIP 


CORE sends SIP 200 OK to UE via Gm 






















SIP 


AS sends SIP to CORE via ISC 
(not described in R2) 






SIP 


CORE sends SIP to PVRS via y2 
(not described in R2) 








IGMPJoin 


PVRS starts recording TV Channel program, at 
"start-time" (not described in R2) 


^ 








IGMP Leave 


PVRS stops recording TV Channel program at 
"end-time" (not described in R2) 








7 






^ 










SIP 


AS sends SIP MESSAGE to CORE via ISC 
(optional may exist prior to IGMP join) 


V 


8 


SIP 


CORE sends SIP MESSAGE to UE via Gm 
(optional may exist prior to IGMP join) 




V 


9 


SIP 


UE sends SIP 200 OK to CORE via Gm 
(optional may exist prior to IGMP join) 






10 


SIP 


CORE sends SIP 200 OK to AS via ISC 
(optional may exist prior to IGMP join) 




11 


















User requests EPG after the end of the 
recorded program 




12 










V 






HTTP 


UE sends HTTP GET to AS via Xa (1 to n times) 








13 


HTTP 


AS sends HTTP 200 OK to UE via Xa (1 to n 
times) 








14 































The AS-IPTV may send additional MESSAGES to the UE to inform something, such as the current recording status. 
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4.4.8.3 Watching a recorded content 



Interoperability Test Description 


Identifier: 


ID IMS IPTV nP2 0003 (S3A-2202) 


Summary: 


User watches a recorded nPVR content 


References: 


TS 1 82 027 [1 ], clause 8.5; TS 1 83 063 [2] 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, PVRS 


^ .„, J 


Pre-test 
conditions: 


• UE, PVRS, Gore IMS and IPTV AS are configured for method 2 

• UE is registered in Gore IMS using userlPTV_priv identity 

• UE supports nPVR 

• EPG has at least one nPVR enabled broadcast TV channel 

• nPVR content is available in PVRS based on either an impulsive or offline request 
to capture broadcast TV channel (see TD_IMS_IPTV_nP2_0001/2) 

• User has nPVR rights in IPTV AS 

• IMS GORE configured to forward nPVR related SIP requests to AS IPTV 

• UE, PVRS and TV Head End support the same content protocols and coding 


Test Sequence: 


Step 






1 


User requests to watch the captured nPVR content 




2 


Verify that UE displays the captured nPVR content 


1 1 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



There are 3 accepted different possibilities for playing the recorded content. 
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1) With relnvite SIP messages for establishing the content dehvery channel: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 

s 


P 

V 
R 
S 














1 


















User requests to watch the recorded nPVR 
content 




2 










N. 






SIP 


UE sends SIP INVITE to CORE via Gm 


^ 




3 


SIP 


CORE sends SIP INVITE to AS via ISC 


y 


4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to PVRS via y2 






6 


SIP 


PVRS sends SIP 200 OK to CORE via y2 




■N. 


7 


SIP 


CORE sends SIP 200 OK to AS via ISC 


y 


8 


SIP 


AS sends SIP 200 OK to CORE via ISC 




9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to PVRS via y2 






14 


RTSP 


UE sends RTSP DESCRIBE to PVRS via Xc 
(optional, only to get missing SDP parameters) 


^ 








15 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 
(optional) 










16 


RTSP 


UE sends RTSP SETUP to PVRS via Xc 










17 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 




V 


V 




18 


SIP 


UE sends SIP relNVITE to CORE via Gm 






19 


SIP 


CORE sends SIP relNVITE to AS via ISC 




20 


SIP 


AS sends SIP relNVITE to CORE via ISC 




21 


SIP 


CORE sends SIP relNVITE to PVRS via y2 






22 


SIP 


PVRS sends SIP 200 OK to CORE via y2 


*. 


>. 


23 


SIP 


CORE sends SIP 200 OK to AS via ISC 


^ 


24 


SIP 


AS sends SIP 200 OK to CORE via ISC 


N. 


25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


SIP 


UE sends SIP ACK to CORE via Gm 






27 


SIP 


CORE sends SIP ACK to AS via ISC 


y 


28 


SIP 


AS sends SIP ACK to CORE via ISC 




29 


SIP 


CORE sends SIP ACK to PVRS via y2 






30 


RTSP 


UE sends RTSP PLAY to PVRS via Xc 










31 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 










32 


SIP 


PVRS sends SIP INFO to CORE via y2 
(optional) 




■N. 


33 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




34 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




35 


SIP 


CORE sends SIP 200 OK to PVRS via y2 
(optional) 






36 




i 














UE displays the recorded nPVR content 
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2) With UPDATE SIP messages for establishing the content delivery channel: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


P 

V 
R 
S 














1 


















User requests to watch the recorded nPVR 
content 




2 












■N. 




SIP 


UE sends SIP INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to PVRS via y2 


^ 




6 


SIP 


PVRS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 


V 


9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to PVRS via y2 




>. 


14 


RTSP 


UE sends RTSP DESCRIBE to PVRS via Xc 
(optional, only to get missing SDP parameters) 










15 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 
(optional) 








>. 


16 


RTSP 


UE sends RTSP SETUP to PVRS via Xc 


^ 








17 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 








>. 


18 


SIP 


UE sends SIP UPDATE to CORE via Gm 


^ 




19 


SIP 


CORE sends SIP UPDATE to AS via ISC 


^ 


20 


SIP 


AS sends SIP UPDATE to CORE via ISC 




21 


SIP 


CORE sends SIP UPDATE to PVRS via y2 






22 


SIP 


PVRS sends SIP 200 OK to CORE via y2 




>. 


23 


SIP 


CORE sends SIP 200 OK to AS via ISC 




24 


SIP 


AS sends SIP 200 OK to CORE via ISC 




25 


SIP 


CORE sends SIP 200 OK to UE via Gm 






26 


RTSP 


UE sends RTSP PLAY to PVRS via Xc 










27 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 






^ 




28 


SIP 


PVRS sends SIP INFO to CORE via y2 
(optional) 


V 




29 


SIP 


CORE sends SIP INFO to AS via ISC 
(optional) 




30 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




31 


SIP 


CORE sends SIP 200 OK to PVRS via y2 
(optional) 






32 




i 














UE is displaying the recorded nPVR content 
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3) With RTSP Channel establishing without session modification: 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


P 

V 
R 
S 














1 


















User requests to watch the recorded nPVR 
content 




2 












■N. 




SIP 


UE sends SIP INVITE to CORE via Gm 






3 


SIP 


CORE sends SIP INVITE to AS via ISC 




4 


SIP 


AS sends SIP INVITE to CORE via ISC 




5 


SIP 


CORE sends SIP INVITE to PVRS via y2 


^ 




6 


SIP 


PVRS sends SIP 200 OK to CORE via y2 






7 


SIP 


CORE sends SIP 200 OK to AS via ISC 




8 


SIP 


AS sends SIP 200 OK to CORE via ISC 


V 


9 


SIP 


CORE sends SIP 200 OK to UE via Gm 






10 


SIP 


UE sends SIP ACK to CORE via Gm 






11 


SIP 


CORE sends SIP ACK to AS via ISC 




12 


SIP 


AS sends SIP ACK to CORE via ISC 




13 


SIP 


CORE sends SIP ACK to PVRS via y2 






14 


RTSP 


UE sends RTSP SETUP to PVRS via Xc 


^ 








15 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 








>. 


16 


RTSP 


UE sends RTSP PLAY to PVRS via Xc 










17 


RTSP 


PVRS sends RTSP 200 OK to UE via Xc 






^ 




18 


SIP 


PVRS sends SIP INFO to CORE via y2 
(optional) 






19 


SIP 


CORE sends SIP INFO to AS via ISC (optional) 




20 


SIP 


AS sends SIP 200 OK to CORE via ISC 
(optional) 




21 


SIP 


CORE sends SIP 200 OK to PVRS via y2 
(optional) 






22 




i 














UE is displaying the recorded nPVR content 



4.4.9 User General Content (UGC) 

UGC (User-generated Content) refers to various kinds of media content, that are produced by end-users 
(TS 181 016 [12], clause A.9.13). 

They are two kinds of UGC procedures: 

• The creation of UGC content: the user is allowed to declare and upload/upstream his own content to the 
network. 

• The watching of UGC content: the user is allowed to select and watch a UGC content. 
Note that SIP messages as 100 TRYING are not included in sequence diagrams below. 



£75/ 



80 



ETSI TS 186 020 V3.1.1 (2011-07) 



4.4.9.1 UGC declaration procedures 



Interoperability Test Description 


Identifier: 


ID IMS IPTV UGC 0001 


Summary: 


UE declares a new UGC content 


References: 


TS 182 027 [1], clause 8.9.2; TS 183 063 [2], clauses 5.1.8.1 and 5.3.5.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS 


^^^■- 


Pre-test 
conditions: 

[ ^^^^^ 


• UE profile is configured to accept UGC procedures 

• UE UGC profile is operational (TS 182 027 [1], clause 7.3.1.18/19) 

• UE is registered in Core IMS using userlPTV priv identity 

• UE has received EPG from IPTV AS (see TD IMS IPTV ADS 0001/2/3) 


1 


Test Sequence: 


Step 




1 


UE sends a UGC content declaration request 


2 


Verify that UE receives the response from AS 


^ 


~^^^^^^H ^^^^^^^^^B ^^^^ 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 








1 




J 














User sends a UGC declaration 


2 




f 




V 


V 






SIP/SDP 


UE sends SIP MESSAGE request including the 
transaction-id and a SDP offer to CORE via Gm 






3 


SIP/SDP 


CORE sends SIP MESSAGE request to AS via 
ISC 




4 


SIP 


AS sends SIP 200 OK response without body to 
CORE via ISC 




5 


SIP 


CORE sends SIP 200 OK response without body 
to UE viaGm 






6 


SIP/SDP 


AS sends SIP MESSAGE request including the 
UGC contentID and the SDP answer to CORE via 
ISC 




7 


SIP/SDP 


CORE sends SIP MESSAGE request to UE via 
Gm 






8 


SIP 


UE sends SIP 200 OK response without body to 
CORE via Gm 






9 


SIP 


CORE sends SIP 200 OK response to AS via ISC 




10 




Verify that UE receives the ContentID identifying 
the UGC content 





















Refer to test description TD_IMS_IPTV_CoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 
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4.4.9.2 UGC creation procedures 

Refer to TS 183 063 [2], clause 5.3.2.1 for the procedure to handling for missing parameters before session initiation. 



Interoperability Test Description 


Identifier: 


TD IMS IPTV UGC 0002 


Summary: 


UE creates a UGC content 


References: 


TS 1 82 027 [1 ], clause 8.9.2; TS 1 83 063 [2], clauses 5.1 .8.3.1 , 5.3.5.3 and 5.4.4.1 


Configuration: 


OF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Gore IMS, IPTV AS, CoDS 


1 *J 


Pre-test 
conditions: 


• UE supports UGC 

• IMS CORE configured to forward UGC related SIP requests to AS IPTV 

• UE profile is configured to accept UGC procedures 

• UE UGC profile is operational (TS 182 027 [1], clauses 7.3.1.18/19) 

• UE is registered in Core IMS using userlPTV_priv identity 

• UE has received EPG from IPTV AS (see TD_ IMS_IPTV_ADS_0001/2/3) 


1 1 


Test Sequence: 


Step 




1 


UE sends a UGC declaration request 


2 


Verify that SCF publishes the new created UGC content 


■^M 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 

D 
S 














1 




> 














User sends an UGC declaration 


2 
















SIP/SDP 


UE sends SIP MESSAGE request including tlie 
transaction-id and a SDP offer to GORE via Gm 


^ 




3 


SIP/SDP 


CORE sends SIP IVIESSAGE request to AS via 
ISC 


^ 


4 




SIP 


AS sends SIP 200 OK response without body to 
CORE via ISC 


^ 


5 




SIP 


CORE sends SIP 200 OK response without body 
to UE viaGm 






6 




SIP/SDP 


AS sends SIP MESSAGE request including UGC 
contentID and the SDP answer to CORE via ISC 




7 




SIP/SDP 


CORE sends SIP MESSAGE request to UE via 
Gm 






8 




SIP 


UE sends SIP 200 OK response without body to 
CORE via Gm 






9 




SIP 


CORE sends SIP 200 OK response to AS via ISC 




11 
















SIP/SDP 


UE sends SIP MESSAGE request including the 
UGC contentID and UGC description information 
to CORE via Gm 


^ 




12 


SIP/SDP 


CORE sends SIP MESSAGE request to AS via 
ISC 


^ 


13 


SIP 


AS sends SIP 200 OK response without body to 
CORE via ISC 




14 


SIP 


CORE sends SIP 200 OK response without body 
to UE viaGm 






15 




User sends UGC initiates UGC session creation 




16 


SIP/SDP 


UE sends SIP INVITE including UGC contentID 
and SDP offer to CORE via Gm 






17 


SIP/SDP 


CORE sends SIP INVITE to AS via ISC 


^ 


18 


SIP/SDP 


AS sends SIP INVITE including UGC contentID 
and SDP offer to CORE via ISC 




19 


SIP/SDP 


CORE sends SIP INVITE to CoDS via y2 






20 
















SIP/SDP 


CoDS sends SIP 200 OK response including SDP 
response to CORE via y2 


^ 








21 
















SIP/SDP 


CORE sends SIP 200 OK response to AS via ISC 


^ 


22 


SIP/SDP 


AS sends SIP 200 OK response to CORE via ISC 




23 


SIP/SDP 


CORE sends SIP 200 OK response to UE via Gm 






24 








> 








SIP/SDP 


UE sends SIP ACK to CORE via Gm 


25 






SIP/SDP 


CORE sends SIP ACK to AS via ISC 


26 




SIP/SDP 


AS sends SIP ACK to CORE using ISC 


^ 


27 




SIP/SDP 


CORE sends SIP ACK to CoDS via y2 




^ 


28 






RTSP 


UE sends a RTSP RECORD to CoDS via Xc 








? 


29 










RTSP 


CoDS sends SIP 200 OK response to UE via Xc 


^ 








30 






^ 












UE sends UGC Publication information 




31 


SIP 


CORE sends SIP MESSAGE request body to AS 
via ISC 




32 


SIP 


AS sends SIP 200 OK response without body to 
CORE via ISC 




33 


SIP 


CORE sends SIP 200 OK response without body 
to UE viaGm 






34 




User requests EPG after the publishing procedure 




35 


HTTP 


UE sends HTTP GET to AS via Xa 


^ 






36 


HTTP 


AS sends HTTP 200 OK to UE via Xa 








37 




User requests EPG 


^ 


38 






Verify that UE displays EPG with the new UGC 
content 
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Refer to test description TD_IMS_IPTV_CoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 

4.4.9.3 UGC watching procedures 

As specified in TS 182 027 [1], clause 8.9.3, the UE may select UGC content on several methods: 

• Selection through SSF, see TS 182 027 [1], clause 8.2 Step 4. 

• Pre-selection. 

Other methods are out of scope. 



4.4.9.3.1 UGC watching procedures: Pre-selection (using Method 2) 



interoperability Test Description 


Identifier: 


TD IMS IPTV UGC 0004 


Summary: 


User requests to watch a UGC content - pre selection (using method 2) 


References: 


TS 182 027 [1], clause 8.9.3; TS 183 063 [2], clauses 5.1.8.4, 5.3.5.4, 5.4.4.2 and 
clause A.3.1 A 


Configuration: 


OF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


1 ^^^K 

Pre-test 
conditions: 


• UE profile is configured to accept UGC procedures 

• UE UGC profile is operational (TS 182 027 [1], clauses 7.3.1.18/19) 

• UE, Core IMS, CoDS and IPTV AS are configured for method 2 

• IMS CORE configured to forward CoD related SIP requests to AS IPTV 

• CoDS configured with UGC contents 

• EPG has at least one UGC content 

• UE is registered in Core IMS using userlPTV priv identity 

• UE has received EPG from IPTV AS (see TD_ IMS_IPTV_ADS_0001/2/3) 

• Users has selected the UGC content to watch 


Test Sequence: 


Step 


n 


1 


Users selects the UGC content to watch 


2 


Verify that UE displays the selected UGC content 


1 1 


Conformance 
Criteria: 


Clieck 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 














1 




> 














Users selects the UGC content to watch 


2 










V 






SIP/SDP 


UE sends SIP MESSAGE request Including the 
UGC contentID to GORE via Gm 






3 


SIP/SDP 


CORE sends SIP MESSAGE request to AS via 
ISC 




4 
















SIP 


AS sends SIP 200 OK response without body to 
CORE via ISC 




5 


SIP 


CORE sends SIP 200 OK response without 
body to UE via Gm 






6 

7 




» 












SIP 


SCF initiates UGC session 

AS sends SIP INVITE without SDP to CORE via 

ISC 


i 




8 


SIP 


CORE sends SIP INVITE without SDP to UE via 
Gm 


i 








9 


SIP/SDP 


UE sends SIP 200 OK response including SDP 
offer to CORE via Gm 






10 


SIP/SDP 


CORE sends SIP 200 OK response to AS via 
ISC 




11 


SIP/SDP 


AS sends INVITE with contentID and SDP offer 
to CORE via ISC 


i 




12 


SIP/SDP 


CORE sends INVITE to CoDS via y2 




^ 


13 






SIP/SDP 


CoDS sends SIP 200 OK response with SDP 
answer to CORE via y2 


^ 








14 


SIP/SDP 


CORE sends SIP 200 OK response to AS using 
ISC 




15 


SIP/SDP 


AS sends SIP ACK to CORE via Gm 


i 


16 




SIP/SDP 


CORE sends SIP ACK to CoDS via y2 




^ 


17 






SIP/SDP 


AS sends SIP ACK with SDP answer to CORE 
via ISC 


i 




18 


SIP/SDP 


CORE sends SIP ACK to UE via Gm 


^ 




19 






RTSP 


UE sends RTSP DESCRIBE to CoDS via Xc 
(optional, only to get missing parameters) 








^ 










20 


RTSP 


CoDS sends RTSP 200 OK to UE via Xc 


i 








21 










RTSP 


UE sends RTSP SETUP to CoDS via Xc 








^ 


22 










RTSP 


CoDS sends RTSP 200 OK to UE via Xc 


i 








23 










RTSP 


UE sends RTSP PLAY to CoDS via Xc 








^ 


24 










RTSP 


CoDS sends RTSP 200 OK to UE via Xc 










25 












Verify that UE displays the requested UGC 
content 


^ 





















Refer to test description TD_IMS_IPTV_CoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 
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4.4.9.3.2 UGC watching procedures: selection througin the SSF (using Method 1 ) 



Interoperability Test Description 



Identifier: 



TD IMS IPTV UGC 0003 



Summary: 



User requests to watch a UGC content - selection through SSF (using method 1 ) 



References: 



TS 182 027 [1], clause 8.9.3; TS 183 063 [2], clauses 5.1.8.4, 5.3.5.4 and 5.4.4.2 



Configuration: 



CF IMS IPTV 



Required 
Equipment: 

Pre-test 
conditions: 



IPTV aware UE, Core IMS, IPTV AS, CoDS 



UE profile is configured to accept UGC procedures 

UE UGC profile is operational (TS 182 027 [1], clauses 7.3.1.18/19) 

IMS CORE configured to forward CoD related SIP requests to AS IPTV 

CoDS configured with UGC contents 

EPG has at least one UGC content 

UE is registered in Core IMS using userlPTV_priv identity 

UE has received EPG from IPTV AS (see TD_ IMS_IPTV_ADS_0001/2/3) 

Users has selected the UGC content to watch 





Test Sequence: 


Step 




1 


Users selects the UGC content to watch 


2 


Verify that UE displays the selected UGC content 


I 






Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 
o 
D 
S 














1 




> 














Users selects the UGC content to watch 


2 
















SIP 


UE sends SIP MESSAGE request including the 
UGC contentID to GORE via Gm 






3 










V 






SIP 


GORE sends SIP IVIESSAGE request to AS via 
ISC 




4 


SIP 


AS sends SIP 200 OK response without body to 
CORE via ISC 




5 


SIP 


CORE sends SIP 200 OK response without 
body to UE via Gm 






6 

7 




» 












SIP/SDP 


User initiates UGC session 

UE sends SIP INVITE with contentID and SDP 

offer to CORE via Gm 






8 


SIP/SDP 


CORE sends SIP INVITE with contentID to AS 
via ISC 




9 


SIP/SDP 


AS sends SIP INVITE with contentID to CORE 
via ISC 


i 




10 


SIP/SDP 


CORE sends SIP INVITE with contentID to 
CoDS via y2 




? 






11 


SIP/SDP 


CoDS sends SIP 200 OK response including 
RTSP session ID and SDP answer to CORE via 

y2 


^ 




> 




12 


SIP/SDP 


CORE sends SIP 200OK to AS via ISC 


13 




SIP/SDP 


AS sends SIP 200OK to CORE via ISC 


i 


14 


> 


SIP/SDP 


CORE sends SIP 200OK to UE via Gm 


i 




15 




> 


SIP/SDP 


UE sends SIP ACK to CORE via Gm 


16 






SIP/SDP 


CORE sends SIP ACK to AS via ISC 


17 




SIP/SDP 


AS sends SIP ACK to CORE via ISC 


^ 


18 




SIP/SDP 


CORE sends SIP ACK to CoDS via y2 




^ 


19 






RTSP 


UE sends RTSP PLAY to CoDS via Xc 








^ 


20 










RTSP 


CoDS sends RTSP 200 OK to UE via Xc 


















21 












Verify that UE displays the requested UGC 
content 


^ 





















Refer to test description TD_IMS_IPTV_CoD1_001 (4.4.5.1 0) for termination at the end of stream. 

4.4.10 Sending Notification 

Note that SIP messages as 100 TRYING are not included in sequence diagrams below. 
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4.4.10.1 Notification in Signalling path 

This test description logic will be used also by Content Recommendation (4.4.19) using specific parameters as 
NotificationReason (see TS 183 063 [2], clause 5.3.6.1). 



Interoperability Test Description 


Identifier: 


TD IMS IPTV Not 0001 


Summary: 


SCF generates and sends a message request for the transport of notification 


References: 


TS 182 027 [1], clause 9.4; TS 183 063 [2], clauses 5.1.9.1 and 5.3.6.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, GoDS 


1 1 


Pre-test 
conditions: 


• UE has initiated trick-play on a live broadcast channel (see 
TD IMS IPTV BG1 0001) 


^^^v 


Test Sequence: 


Step 




1 


User is watching BC channel 


2 


SCF receives a trick play reports from MF 




3 


Verify that UE presents the received notification to the user 


^^^^^^^F — '* — "^ 




Conformance 
Criteria: 


Check 


^ 


1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 

D 
S 














1 












« 






SCF receives a trick play reports from MF 


2 






f 




^ 






SIP 


AS sends SIP MESSAGE to CORE via ISC 




3 


SIP 


CORE sends SIP MESSAGE to UE via Gm 






4 


SIP 


UE sends SIP 200 OK response to CORE via 
Gm 






5 


SIP 


CORE sends SIP 200 OK response to AS via 
ISC 




6 


















Verify that UE presents the received notification 
to the user 





















Refer to test description TD_IMS_IPTV_CoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 



4.4.11 Instant Messaging 



The UE shall support DMA Instant Messaging according to [13] and [14]. 

Note that SIP messages as 100 TRYING are not included in sequence diagrams below. 
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4.4.1 1 .1 Instant Messaging Sending 



Interoperability Test Description 


Identifier: 


ID IMS IPTV IM 0001 


Summary: 


User sends an instant message through OMA Instant Messaging 


References: 


TS 182 027 [1], clause 9.3.1; TS 183 063 [2], clauses 5.1.17.1 and 5.3.16.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS 


^^^m. 


Pre-test 
conditions: 


• UE supports OMA Instant Messaging 

• UE is registered in Gore IMS using userlPTV priv identity 


^^^ 


Test Sequence: 


Step 




1 


User registers to OMA Instant Messaging service 


2 


User sends "Available soon?" IM 


3 


Verify that UE receives SIP 200 OK 


^^m 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 








V 


V 








User registers to OMA Instant Messaging 
service 


^ 


2 




UE sends SIP REGISTER request including 
OMA feature tag [14] to CORE via Gm 






3 




GORE sends SIP REGISTER request to AS via 
ISG 


^ 


4 




AS sends SIP 200 OK response to GORE via 
ISG 


V 


5 




GORE sends SIP 200 OK response to UE via 
Gm 






6 




UE sends "Available soon?" IM 


7 




SIP 


UE sends SIP MESSAGE with specified header 
to GORE via Gm 


^ 




8 


SIP 


GORE sends SIP MESSAGE with specified 
header to AS via ISG 


^ 


9 


SIP 


AS sends SIP 200 OK response to GORE via 
ISG 




10 




SIP 


GORE sends SIP 200 OK response to UE via 
Gm 






11 




«— 






















UE receives SIP 200 OK 



Refer to test description TD_IMS_IPTV_GoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 
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4.4.1 1 .2 Instant Messaging Receiving 



Interoperability Test Description 


Identifier: 


ID IMS IPTV IM 0002 


Summary: 


User receives an instant message tlirough OMA Instant Messaging 


References: 


TS 182 027 [1], clause 9.3.1 ; TS 183 063 [2], clauses 5.1.17.1 and 5.3.16.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS 


^^^■- 


Pre-test 
conditions: 


• UE supports OMA Instant Messaging 

• UE is registered in Core IMS using userlPTV_priv identity 

• UE is registered to OMA IM service (see TD IMS IPTV IM 0001) 


^^^^^^^^^^^ 




^^ 


Test Sequence: 


Step 




1 


An Instant Message is required to be sent to UE 


2 


Verify that UE displays the received IM 


I 


^^^^^^H 


J 


Conformance 
Criteria: 


Check 


1 


1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 












i 






An Instant Message is required to be sent to UE 


3 






« 




K 








GORE sends SIP MESSAGE to UE via Gm 


4 








^ 










UE sends 200 OK to CORE via Gm 


5 
6 




i 






^ 








CORE sends 200 OK to AS via ISC 
Verify that UE displays the received IM 



Refer to test description TD_IMS_IPTV_CoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 

4.4.12 PushCoD 

Note that SIP messages as 100 TRYING are not included in sequence diagrams below. 
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4.4.1 2.1 UE-initiated Content download for unicast download 

Refer to TS 183 063 [2], clause 5.3.2.1 for the procedure to handling for missing parameters before session initiation. 



Interoperability Test Description 


Identifier: 


TD IMS IPTV pCoD 0001 


Summary: 


User request to download a CoD content 


References: 


TS 182 027 [1], clauses 8.17.1 and 8.18.2; TS 183 063 [2], clauses 5.1.18.1, 5.4.1.2 
and 6.5.1.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, GoDS 


^^^^^ 


Pre-test 
conditions: 


• Refer to test description TD_IMS_IPTV_CoD1_0001 




Test Sequence: 


Step 




1 


User requests to download a CoD content 


2 


Verify that UE has downloaded the expected content 


I 


^^^ 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


c 



D 
S 














1 




» 














User requests to download a CoD 


2 










N. 






SIP/SDP 


UE sends SIP INVITE including the contentID 
and the download content URI and a SDP offer 
to CORE via Gm 






3 


SIP/SDP 


GORE sends SIP INVITE to AS via ISC 


^ 


4 


SIP/SDP 


AS sends SIP INVITE to GORE via ISC 




5 


SIP/SDP 


GORE sends SIP INVITE to GoDS via y2 


^ 




6 


SIP/SDP 


CoDS sends SIP 200 OK response to GORE via 
V2 


V 


N. 


7 


SIP/SDP 


GORE sends SIP 200 OK response to AS via 
ISC 




8 


SIP/SDP 


AS sends SIP 200 OK response to GORE via 
ISC 




9 


SIP/SDP 


GORE sends SIP 200 OK response to UE via 
Gm 






10 


SIP/SDP 


UE sends SIP ACK to GORE via Gm 






11 


SIP/SDP 


GORE sends SIP ACK to AS via ISC 




12 


SIP/SDP 


AS sends SIP ACK to CORE via ISC 




13 


SIP/SDP 


GORE sends SIP ACK to CoDS via y2 






14 


HTTP 


UE sends HTTP GET request with header 
"Connection" set to "Keep Alive" via Xd 


f 








15 


HTTP 


CoDS sends HTTP response via Xd 










16 




^ 














Verify that UE has downloaded the expected 
content 





















Note that this test description will be reused in clause 4.4.9.10 because of the test logic is identical, only SDP offer 
parameters shall be changed as the type of content element: it shall be set to "streaming" (see TS 183 063 [2], 
clause 5.1.18.1 bullet 6). 

Refer to test description TD_IMS_IPTV_GoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 
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4.4.1 2.2 UE-initiated Content download for unicast progressive download 

Refer to test description 4.4.9.8 for the logic of the test description. Modifying SDP offer parameters (as the type of 
content element set to "progressive") permits to cover all test descriptions. 

4.4.13 Targeted Ad Insertion (TAI) - SCTE 

These test descriptions cover delivery of personalised advertising to subscribers. The clauses below depict the general 
procedure for targeted Ad insertion (see TS 182 027 [1], clause 8.14). 

Note that SIP messages as 100 TRYING are not included in sequence diagrams below. 

4.4.13.1 TAI by notification at UE side 

In this test description, we assume that UE initiates a separate session to MF that includes the target Ad content 
(see TS 182 027 [1], clause 8.14.2.1 step 6). 



Interoperability Test Description 


Identifier: 


TD IMS IPTV TAI2 0001 


Summary: 


User receives an advertising message 


References: 


TS 182 027 [1], clauses 8.14.2.1 and E.2; TS 183 063 [2], clauses 5.1.15.1 and 5.3.14 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, GoDS 


1 1 


Pre-test 
conditions: 

1 


• UE subscription is configured to accept Advertising service 

• The UE is watching CoD content (see TD_IMS_IPTV_GoD1_0001 ) 

• SCF is connected to at least one Ad Server (see clause E.2.4.2.1 ) 


I 

Test Sequence: 


Step 




1 


SCF sends Ad message to UE 


2 


Verify that UE displays the Advertising message without interruption of 
watching CoD 


1 - 


^^^^^ 


1 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 

D 
S 








1 1 1 1, 1 




— — — 


1 
2 




> 








^ 

» 




SIP 


SCF sends Advertising message to UE 

AS sends SIP MESSAGE request to CORE via 

ISC 


> 


3 


SIP 
<5ip 


CORE sends SIP IVIESSAGE request to UE via 
Gm 

1 IF conHc 900 C\\C \c\ PORP \/ia 0,rr\ 






5 






SIP 


CORE sends 200 OK to AS via ISC 


6 

7 




> 


<5ip/c;np 


UE initiate s a session for content insertion 

1 IP conrlc Clip IM\/ITP tn PORP \/ia 0,m 


8 


^ 




SIP/SDP 


CORE sends SIP INVITE to AS via ISC 


9 

10 


k 


blr/oUr 
SIP/SDP 


Ab sends olr INVI I c to OUHb via loU 
CORE sends SIP INVITE to CoDS via y2 


11 






SIP 


CoDS sends SIP 200 OK response to CORE via 
y2 




» 


12 


SIP 


CORE sends SIP 200 OK response to AS via 
ISC 


^ 


13 


SIP 


AS sends SIP 200 OK response to CORE via 
ISC 


> 


14 
1 R 


SIP 

9IP 


CORE sends SIP 200 OK response to UE via 

Gm 

1 IF qpririq '^IP APK tn PORP via Rm 






16 






SIP 


CORE sends SIP ACK to AS via ISC 


17 
18 


< 


bIP 
SIP 


Ab sends bIP ACK to CORE vi IbC 
CORE sends ACK to CoDS via y2 


19 




» 


RTSP 


UE sends RTSP PLAY to CoDS via Xc 


20 
21 


d 








RTSP 


CoDS sends RTSP 200 OK to UE via Xc 
UE displays the Advertising message without 
interruption of watching CoD 





















Refer to test description TDIMSIPTVCoDIOOl (4.4.5.1 0) for normal session termination at the end of stream. 

4.4.13.2 TAI by content insertion at UE side 

In this test description, we assume that UE initiates a separate session to MF that includes the target Ad content 
(see TS 182 027 [1], clause 8.14.2.1 step 6). 



Interoperability Test Description | 


Identifier: 


TD IMS IPTV TAI2 0002 


Summary: 


User receives an advertising message 


References: 


TS 182 027 [1], clauses 8.14.2.1 and E.2; TS 183 083 [2], clauses 5.1.15.2 and 5.3.14 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, CoDS 


1 1 


Pre-test 
conditions: 


• UE subscription is configured to accept Advertising service 

• The UE is watching CoD content (see TDJMS_IPTV_CoD1_0001 ) 

• SCF is connected to at least one Ad Server (see clause E.2.4.2.1) 




Test Sequence: 


Step 




1 


SCF sends Ad message to UE 


2 


Verify that UE displays the Advertising message without interruption of 
watching CoD 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


C 

D 
S 














1 




» 














SCF sends Advertising message to UE 


^ 


2 




SIP 


AS sends SIP INFO request including 
"ContentlnsertionReason" element set to 
"Advertising" to CORE via ISC 


i 


> 


3 


SIP 


CORE sends SIP INFO request to UE via Gm 


i 




4 




> 


SIP 


UE sends 200 OK to CORE via Gm 


5 




» 


SIP 


CORE sends 200 OK to AS via ISC 


6 




> 




UE initiate s a session for content insertion 


7 


SIP/SDP 


UE sends SIP INVITE to CORE via Gm 


8 






SIP/SDP 


CORE sends SIP INVITE to AS via ISC 


9 




SIP/SDP 


AS sends SIP INVITE to CORE via ISC 


i 


10 




SIP/SDP 


CORE sends SIP INVITE to CoDS via y2 




^ 


11 






SIP 


CoDS sends SIP 200 OK response to CORE via 
y2 


^ 




V 




12 


SIP 


CORE sends SIP 200 OK response to AS via 
ISC 




13 


SIP 


AS sends SIP 200 OK response to CORE via 
ISC 


i 


> 


14 


SIP 


CORE sends SIP 200 OK response to UE via 
Gm 


i 






> 


15 


SIP 


UE sends SIP ACK to CORE via Gm 


16 






SIP 


CORE sends SIP ACK to AS via ISC 


17 




SIP 


AS sends SIP ACK to CORE vi ISC 


^ 


18 




SIP 


CORE sends ACK to CoDS via y2 




^ 


19 






RTSP 


UE sends RTSP PLAY to CoDS via Xc 








^ 


20 










RTSP 


CoDS sends RTSP 200 OK to UE via Xc 


i 








21 












UE displays the Advertising message without 
interruption of watching CoD 


^ 





















Refer to test description TD_IMS_IPTV_CoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 

4.4.1 3.3 TAI by content insertion at MF side 

Refer to test description above (see TS 183 063 [2], clause 5.1.15.2). 

4.4.14 Emergency Information 

We assume that the user is located in its home network. If not, UE is required to perform an IMS emergency 
registration. 

Note that SIP messages as 100 TRYING are not included in sequence diagrams below. 
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4.4.14.1 Emergency Information by Notification 

Refer to test description TD_IMS_IPTV_CoD1_0001, Start CoD to achieve pre-conditions. 



Interoperability Test Description 


Identifier: 


ID IMS IPTV EMI 0001 


Summary: 


UE receives an emergency alert 


References: 


TS 182 027 [1], clauses 15 bullets 1 and 8.11.1.1 


Configuration: 


OF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, GoDS 


1 ^ 


^ 


Pre-test 
conditions: 


• UE is registered in Gore IMS using userlPTV_priv identity 

• UE is registered in home network 

• UE is watching GoD as described by TD IMS IPTV CoD1 0001 


Test Sequence: 


Step 




1 


An emergency event is triggered on SCF 




2 

J 


Verify that TV watching is interrupted and the user is alerted 


1 


Conformance 
Criteria: 


- J 
Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 


















An emergency event is triggered on SGF 


2 










f 






SIP 


AS sends SIP MESSAGE including header field 
Priority set to "emergency" to GORE via ISG 




3 






« 










SIP 


GORE sends SIP MESSAGE to UE via Gm 


4 








^ 








SIP 


UE sends 200 OK to GORE via Gm 


5 
6 




f 






> 






SIP 


GORE sends 200 OK to AS via ISG 

TV watching is interrupted and the user is 

alerted 





















Refer to test description TD_IMS_IPTV_GoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 
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4.4.14.2 Emergency Information by Content Insertion 

Refer to test description TD_IMS_IPTV_BC_0001, Session initiation without RACS for broadcast TV to achieve 
pre-conditions. 



Interoperability Test Description 


Identifier: 


TD IMS IPTV EMI 0002 


Summary: 




References: 


TS 1 82 027 [1 ], clauses 1 5 bullet 2 and 8.11 . 1 .2; TS 1 83 063 [2], clause 5.3.1 2.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS, GoDS 


1 1 


Pre-test 
conditions: 


• UE Is registered In Core IMS using userlPTV_prlv identity 

• UE Is registered In home network 

• UE Is watching broadcast TV as described by TD IMS IPTV BO 0001 






Test Sequence: 


Step 




1 


An emergency event Is triggered on SGF to MF 




2 


Verify that TV watching Is Interrupted and the user is alerted 


^^^ 


Conformance 
Criteria: 


Check 


j»i 


1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 


c 


D 
S 














1 


















An emergency event Is triggered on SGF 


2 










^ 






SIP 


AS sends SIP MESSAGE Including header field 
Priority set to "emergency" to GORE via ISG 




3 
















SIP 


GORE sends SIP MESSAGE Including header 
field Priority set to "emergency" to GoDS via y2 






4 






^ 










SIP 
<5IP 


GoDS sends SIP INFO message to GORE via 
y2 






6 








» 








SIP 


UE sends 200 OK to GORE via Gm 


7 












— » 




SIP 


GORE sends 200 OK to GoDS via y2 


8 
9 










< 

^ 






SIP 
SIP 


GoDS sends 200 OK to CORE via y2 
GORE sends 200 OK to AS via ISG 


10 


















TV watching Is interrupted and the user Is 
alerted 





















Refer to test description TD_IMS_IPTV_GoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 

4.4.15 Incoming call management 

In the test descriptions below, the same user B has two devices (UE): 

• An IPTV device, identified by UE B or UE B 1 

• A phone device, identified by UE B2 

The user A calls the user B and user B could accept or reject the incoming call. 

The clauses below depict different Incoming Call behavior: 

1) Incoming Call Rejection (4.4.9.18): The User B does not answer to the notification message (call rejection on 
notification time out) 
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2) Incoming Call Acceptance (4.4.9.19): The User B accepts the incoming call answering to the notification 
message, the call is sends on the IPTV device 

3) Incoming Call Forwarding (4.4.9.20): The User B accepts the incoming call answering to the notification, the 
call is sends on the phone device 

4.4.15.1 Incoming call notification 

Refer to Notification test description (4.4.9.4) using specific parameters as described in TS 183 063 [2], clause 5.3.6.1 
(NotificationReason set to IncomingCall...). IncomingCalllnfo shall be set to the information of the caller. 

4.4.15.2 Incoming call handling 

Refer to Incoming Call test descriptions below for Incoming Call handling (TS 182 027 [1], clause 9.2.1). 

4.4.15.3 Incoming call rejection 

This test description depicts the following procedure: 

• User B is watching BC TV 

• User A calls User B 

• User B is notified of the incoming call 

• User B ignore the notify message (time out) 

Note that SIP messages as 100 TRYING are not included in sequence diagrams below. 



Interoperability Test Description 


Identifier: 


TD IMS IPTV ICM 0001 


Summary: 




References: 


TS 182 027 [1], clauses 9.2.1 and 9.2.2; TS 183 063 [2], clause 5.3.6.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE B, Core IMS, IPTV AS, UE A 


^^^m. 


Pre-test 
conditions: 


• UE B is registered in Core IMS using userlPTV_priv identity 

• UE B is registered in home network 

• UE B is watching broadcast TV as described by TD IMS IPTV BC 0001 




Test Sequence: 


Step 




1 


UEAcallsUEB 




3 


UE B refused the incoming call 




4 


Verify that TV signal was not interrupted 


^~ ■ 


^^K^^T" i^^^^M ^^^^ 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 
B 


U 

E 

B 


T 
& 
A 


C 

R 

E 


A 
S 


U 
s 
e 
r 
A 














1 










^ 








An incoming call is received by CORE from UE 
A 






2 










> 






SIP/SDP 


CORE sends SIP INVITE request to AS via ISC 


3 
















SIP/SDP 


AS sends SIP MESSAGE with IncomingCalllnfo 
to CORE via ISC (optional) 




4 
















SIP/SDP 


CORE sends SIP MESSAGE to UE B via Gm 
(optional) 






5 




^ 














Verify that UE B is informed of Incoming call 
(optional) 




6 

7 










^ 






<5ip 


UE B does not answer after timeout 

A<5 conric C;|p PAMI^CI trv PORF \/ia l^ir^ 


8 












» 




SIP 


CORE sends SIP CANCEL to UE A 


9 










i 






SIP 


UE A sends SIP 200 OK to CORE 


10 
11 




i 






> 






SIP 


CORE sends SIP 200 OK to AS via ISC 
Verify that TV signal was not interrupted 



Refer to test description TD_IMS_IPTV_CoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 



4.4.15.4 Incoming call acceptance on IPTV UE 

This test description depicts the following procedure: 

• User B is watching BC TV 

• User A calls User B 

• User B is notified of the incoming call 

• User B accepts the incoming call on TV 

Note that SIP messages as 100 TRYING and 183 SESSION PROGRESS are not included in sequence diagrams below. 
By the way, 183 SESSION PROGRESS message shall be checked. 



Interoperability Test Description 


Identifier: 


TD IMS IPTV ICM 0002 


Summary: 




References: 


TS 182 027 [1], clause 9.2.2; TS 183 063 [2], clause 5.3.6.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE B, Core IMS, IPTV AS, UE A 


Pre-test 
conditions: 


• UE B is registered in Core IMS using userlPTV_priv identity 

• UE B is registered in home network 

• UE Bis watching broadcast TV as described by TD IMS IPTV BC 0001 


Test Sequence: 


Step 




1 


UEAcallsUEB 




2 


Verify that UE B is notified 




3 


UE B accepts the incoming call 




4 


Verify that UE A and UE B are connected 


^" ~i 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 
B 


U 

E 

B 


T 
& 
A 


C 

R 

E 


A 
S 


U 
s 
e 
r 
A 














1 


















An incoming call is received by CORE from UE 
A 


i 








2 










» 






SIP/SDP 


CORE sends SIP INVITE request to AS via ISC 


3 
















SIP/SDP 


AS sends SIP IVIESSAGE with IncomingCalllnfo 
to CORE via ISC (optional) 


i 




4 
















SIP/SDP 


CORE sends SIP MESSAGE to UE B via Gm 
(optional) 


^ 








5 


















Verify that UE B is informed of incoming call 
(optional) 




6 
















SIP/SDP 


UE B sends SIP 200 OK to CORE via Gm (UE B 
accepts the incoming call) 






7 










> 






SIP/SDP 


CORE sends SIP 200 OK to AS via ISC 


8 
















SIP/SDP 


AS sends SIP INVITE request to CORE via ISC 


^ 


9 
















SIP/SDP 


CORE sends SIP INVITE to UE B via Gm 


^ 




10 








> 








SIP/SDP 


UE B sends SIP 200 OK to CORE via Gm 


11 










» 






SIP/SDP 


CORE sends SIP 200 OK to AS via ISC 


12 
















SIP/SDP 


AS sends SIP 200 OK to CORE via ISC 


^ 


13 
















SIP/SDP 


CORE sends SIP 200 OK to UE A 




^ 


14 


















Verify that TV signal is paused and phone is 
ringing 


^ 




15 








> 








SIP/SDP 


UE B sends SIP ACK to CORE via Gm 


16 










» 






SIP/SDP 


CORE sends SIP ACK to AS via ISC 


17 
















SIP/SDP 


AS sends SIP ACK to CORE via ISC 


^ 


18 
















SIP/SDP 


CORE sends SIP ACK to UE A 




^ 


19 


















Verify that UE A and UE B are connected 


i 



















Refer to test description TD_IIVIS_IPTV_CoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 

4.4.1 5.5 Incoming call forwarding to other UE 

This test description depicts the following procedure: 

UE B 1 has registered call forward to User B2 

UE Bl is watching BC TV 

UEAcallsUEBl 

UE B2 is notified of the incoming call 

UE B2 accepts the incoming call 

Note that SIP messages as 100 TRYING and 183 SESSION PROGRESS are not included in sequence diagrams below. 
By the way, 183 SESSION PROGRESS message shall be checked. 
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Interoperability Test Description 


Identifier: 


ID IMS IPTV ICM 0003 


Summary: 




References: 


TS 182 027 [1], clause 9.2.2; TS 183 063 [2], clause 5.3.6.1 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE B, Core IMS, IPTV AS, UE A 


r 1 


Pre-test 
conditions: 


• UE B1 and User 82 are registered in Core IMS using userlPTV_priv identity 

• UE 81 is registered in home network 

• UE 81 is watching broadcast TV as described by TD_IMS_IPTV_8C_0001 

• UE 81 has registered call forward to User 82 


1 1 


Test Sequence: 


Step 




1 


UE A calls UE 81 , call is forwarded to UE 82 




2 


Verify that UE 8 is notified 




3 


UE 8 accepts the incoming call 




4 


Verify that UE A and UE 8 are connected 


^M~ 


^^^^^F 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 

e 

r 

B1 


U 

E 

B1 


U 
s 
e 
r 
B2 


C 

R 

E 


A 
S 


U 
s 
e 
r 
A 














1 


















An incoming call is received by CORE from UE 
A 






2 










> 






SIP/SDP 


CORE sends SIP INVITE request to AS via ISC 


3 
















SIP/SDP 


AS sends SIP MESSAGE with IncomingCalllnfo 
to CORE via ISC (optional) 




4 






^ 










SIP/SDP/SD 
P 


CORE sends SIP MESSAGE to UE 81 via Gm 
(optional) 






5 


















Verify that UE 81 is informed of incoming call 
(optional) 




6 
















SIP/SDP 


UE 81 sends SIP 200 OK to CORE via Gm (UE 
8 accepts the incoming call) 






7 

Q 










^ 






SIP/SDP 

C 1 D /c n D 


CORE sends SIP 200 OK to AS via ISC 


9 








i 


i 






SIP/SDP 


CORE sends SIP INVITE to UE 82 via Gm 


10 








» 








SIP/SDP 


UE 8 sends SIP 200 OK to CORE via Gm 


12 










? 

i 






SIP/SDP 

C 1 D /c n D 


AS sends SIP 200 OK to CORE via ISC 
r^r^Dc o/-»nj-ic^ ciD or\r\ r^i^ tn \ \c /\ 


14 




^ 








^ 






Verify that TV signal is not interrupted on UE 
81 paused and phone is ringing 




15 

1 fi 
















ciip/cinp 


Verify that UE 82 is ringing 

1 IP RC conrlc CilP APK tn PDRF \;ia dm 


17 










> 






SIP/SDP 


CORE sends SIP ACK to AS via ISC 


\ o 
18 




i 








? 






Verify that UE A and UE B2 are connected 



Refer to test description TD_IMS_IPTV_CoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 
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4.4.16 Time Shifted TV 



The Time Shift TV (tsTV) service allows user to view a video content that has already been broadcasted. In order to 
enable TsTV IPTV SP needs to record content in the MDF. IPTV SP may limit BC content available for TsTV. The 
logic for TsTV is very similar to that introduced for nP VR. The main difference resides in duration of expiration time: 
for TsTV, the expiration time is very short (some few minutes). In consequence, the test description logics are also very 
close to that introduced by Impulsive recording request and Watching a recorded content (refer to test descriptions 
TD_IMS_IPTV_nP2_0001 and TD_IMS_IPTV_nP2_0003). 

4.4.17 Parental Control 

For test descriptions below, the IPTV user profile shall be modified to set the parental control level. 

4.4.1 7.1 Parental Control applied for BC 

Referring to test descriptions TD_IMS_IPTV_BC_0001 (4.4.2.1) and TD_IMS_IPTV_BC_0005 (4.4.2.5) for the logic of 
the test, add the checks listed below: 

1) Check that EPG is filtered correctly, this means that channels not compatible with parental control level 

2) SCF shall refused a BC request not compatible with parental control level 

4.4.1 7.2 Parental Control applied for CoD 

Referring to test description TD_IMS_IPTV_CoD1_0001 (4.4.5.1) for the logic of the test, add the checks Hsted below: 

1) Check that EPG is filtered correctly, this means that channels not compatible with parental control level 

2) SCF shall refused a CoD content request not compatible with parental control level 

4.4.1 7.3 Parental Control applied for UGC 

Referring to test description TD_IMS_IPTV_UGC_0004 (4.4.5) for the logic of the test, add the checks Hsted below: 

1) Check that EPG is filtered correctly, this means that channels not compatible with parental control level 

2) SCF shall refused a UGC content request not compatible with parental control level 

4.4.1 7.4 Parental Control applied for PVR 

Referring to test descriptions TD_IMS_IPTV_nP1_0001 (4.4.7.1), TD_IMS_IPTV_nP1_0002 (4.4.7.2) and 
TD_IMS_IPTV_nP1_0003 (4.4.7.3) for the logic of the test, add the checks Hsted below: 

1) Check that EPG is filtered correctly, this means that channels not compatible with parental control level 

2) SCF shall refused a n-PVR content request not compatible with parental control level 

4.4.18 Content Marker Service (CM) 

This feature allows users to bookmark content (entire movies/channels or individual scenes) for sharing with other 
users. 

4.4.18.1 Creating, updating and querying Content Marker (CM) 

Using parameters, this test description logic covers procedure applied to creating (IPTVContentMarkerlD provided by 
UE does not exist), updating and querying (IPTVContentMarkerlD provided by UE exists) Content Marker. We assume 
that Content Marker procedures occur within an existing SIP session. 
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Interoperability Test Description 


Identifier: 


TD IMS IPTV CM 0001 


Summary: 


UE creates, update or queries a Content Marker 


References: 


TS 1 83 063 [2], clauses 5.1 .14.1 and 6.1 .1 .7 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS 


r 






Pre-test 
conditions: 


• The SCF must have indicated its willingness to receive the IPTV-Content-Marke 
Info Package 

• The UE is watching CoD content (see TDJMS_IPTV_CoD1_0001 ) 


r 
J 


Test Sequence: 


Step 




1 


User creates a Content Marker 


2 


Verify that the Content Marker was created 


^^^^^^ ^^^^v ^ 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 








1 




















2 
















SIP 


UE sends SIP INFO including IPTV-Content- 
Marker Info Package to CORE via Gm 






3 










> 






SIP 


CORE sends SIP INFO to AS via ISC 


4 
















SIP 


AS sends SIP 200 OK response to CORE via 
ISC 




5 






^ 










SIP 


CORE sends SIP 200 OK response to UE via 
Gm 






6 




5> 














Verify that the Content Marker was created 


7 
















HTTP 


UE sends HTTP POST request including the 
domain name of the SSF to AS via Xa 








8 






i 










HTTP 


AS sends HTTP 200 OK to UA via Xa 


9 
















XML 


Evaluate payload in HTTP response to verify 
that UE received to correct Content Marker 





















Refer to test description TD_IMS_IPTV_CoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 
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4.4.1 8.2 Removing Content Marker (CM) 

We assume that removing Content Marker occurs outside an existing SIP session. 



Interoperability Test Description 


Identifier: 


ID IMS IPTV CM 0002 


Summary: 


UE removes a Content Marker 


References: 


TS 1 83 063 [2], clauses 5.1 .14.1 and 6.1 .1 .7 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, IPTV AS 


1 J 


Pre-test 
conditions: 

1 


• The UE is register to CORE IMS 

• The UE has retrieved EPG (see clause 4.4.1) 

• The SCF must have indicated its willingness to receive the IPTV-Content-Marker 
Info Package 

• At least one Content Marker was created 


I 

Test Sequence: 

1 


Step 


^^^^M_ ^^ 


1 


User removes a Content Marker 


2 


Verify that the Content Marker was removed 


1 ^^H 

Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 




> 














User removes a Content Marker 


2 
















SIP 


UE sends SIP MESSAGE including IPTV- 
Content-Marker Info Package to CORE via Gm 






3 










^ 






SIP 


CORE sends SIP MESSAGE to AS via ISC 


4 
















SIP 


AS sends SIP 200 OK response to CORE via 
ISC 




5 
















SIP 


CORE sends SIP 200 OK response to UE via 
Gm 






6 




> 














Verify that the Content Marker was removed 


7 
8 










N. 






HTTP 
HTTP 


UE sends HTTP POST request including the 

domain name of the SSF to AS via Xa 

AS sends HTTP 404 Not Found to UA via Xa 






i 











Refer to test description TD_IMS_IPTV_CoD2_0007 (4.4.6.7) - Step 8 for normal session termination initiated by UE. 

4.4.19 Content Recommendation (CR) 

Refer to Notification test description (4.4.9.4) using specific parameters as described in TS 183 063 [2], clause 5.3.6.1 
(NotificationReason set to ContentRecommendation...) and TS 182 027 [1], clause 8.13. 

4.4.20 Presence 

Note that SIP messages as 100 TRYING and 183 SESSION PROGRESS are not included in sequence diagrams below. 
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4.4.20.1 Subscribing to presence 



Interoperability Test Description 


Identifier: 


ID IMS IPTV PRE 0001 


Summary: 


UE subscribes to Presence service 


References: 


TS 182 027 [1], clause 9.1, TS 183 063 [2], clauses 5.1.6, 5.1.6.1 and annex E 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, Presence server, CoD 


^^^■- 


Pre-test 
conditions: 


• The UE is register to CORE IMS 

• The UE is registered on CoD (refer to TD_IMS_IPTV_CoD1_0001 for the details of 
CoD session initiation procedure) 






Test Sequence: 


Step 




1 


Verify that UE displays the "available" presence status 


1 1 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 


















UE has completed The CoD session initiation 
procedure 




2 




SIP/XML 


UE sends SIP SUBSCRIBE message to CORE 
viaGm 






3 


SIP/XML 


CORE sends SIP SUBSCRIBE message to AS 
via ISC 


>■ 


4 


SIP 


AS sends SIP 200 OK including the expiration 
time to CORE via ISC 




5 


f 


^ 




SIP 


CORE sends SIP 200 OK including the 
expiration time to UE via Gm 






6 


SIP/XML 


UE sends SIP PUBLISH message including 
CoDServicePresence XML element to CORE via 
Gm 


k 




7 


SIP/XML 
<5ip 


CORE sends SIP PUBLISH message including 
CoDServicePresence XML element to AS via 
ISC 

AQ conHc QIP 900 C\K \c\ PHRP \/ia IQP 


^ 


9 




SIP 


CORE sends SIP 200 OK to UE via Gm 


10 








Verify that UE displays the "available" presence 
status 





















Refer to test description TDIMSJPTVCoDIOOOl (4.4.5.1) for normal session termination. 
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4.4.20.2 Receiving presence notifications 



Interoperability Test Description 


Identifier: 


ID IMS IPTV PRE 0002 


Summary: 


UE subscribes to Presence service 


References: 


TS 182 027 [1], clause 9.1, TS 183 063 [2], clause 5.1.6.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, Presence server, CoD 


^^^m. 


Pre-test 
conditions: 


• The UE is register to CORE IMS 

• The UE has subscribed to Presence service (refer to TD IMS IPTV PRE 0001) 


^^^^ 


Test Sequence: 


Step 




1 


UE receive a presence notification message 


2 


Verify that UE displays the display the presence information 


i 




1 


Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 


T 
& 
A 


C 

R 

E 


A 
S 
















1 




» 






f* 








UE has subscribed to Presence service 


2 


i 


SIP/XML 


AS sends SIP NOTIFY message to CORE via 
ISC 






3 


SIP/XML 
<5ip 


GORE sends SIP NOTIFY message to UE via 
Gm 

1 IP conHc Clip onr\ ClK tn I^ORP \/ia dm 






5 






SIP 


GORE sends SIP 200 OK to AS via ISG 


6 














Verify that UE displays the presence information 



Refer to test description TD_IMS_IPTV_GoD1_0001 (4.4.5.1) for normal session termination. 

4.4.21 Service Continuation 

An example of Service Continuation occurs when a user A in watching a CoD or BC content on a first IPTV device (an 
IPTV mobile for instance), he decides to transfer the current watching session on a second IPTV device (his computer) 
without interruption of the content. The Service Continuation proceeds in two stages: the pause procedure and the 
restart procedure. 
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4.4.21.1 Service Continuation between IPTV UEs 



Interoperability Test Description 


Identifier: 


ID IMS IPTV ST2 0001 


Summary: 


UE initiates a CoD content transfer 


References: 


TS 183 063 [2], clause 5.1.20.2 


Configuration: 


CF IMS IPTV 


Required 
Equipment: 


IPTV aware UE, Core IMS, Presence server, CoD 


^^^■- 


Pre-test 
conditions: 


• The UEA is register to CORE IMS 

• The UEA is watching a CoD content (refer to refer to TD_IMS_IPTV_CoD1_0001) 

• User has selected the transferee: UE B, UE A is the transferor 


^^^^^^^^^^" 




Test Sequence: 


Step 




1 


UE A initiates the transfer to UE B 


2 


Verify that UE A watching session is terminated 


3 


Verify that UE B displays the same content from the correct play time 




^^^^^* 




Conformance 
Criteria: 


Check 




1 


Message exchange follows the below table 



Step 


Direction 


Protocol 


Comment 




U 
s 

e 
r 


U 

E 
A 


U 

E 
B 


C 

R 

E 


A 
S 


C 



D 
s 














1 




« 






V 








UE A displays CoD content 


2 
3 


> 


RTSP 


User request a watching session transfer 
UE A sends a RTSP PAUSE including the 
current play time to CoDs via Xc 








4 
5 






« 


V 








RTSP 
SIP/SDP 


CoDs sends RTSP 200 OK to UE A via Xc 
UE A sends SIP REFER request including the 
GRUU of the target device and the IPTV 
Content Marker to CORE via Gm 






6 












>. 




SIP/SDP 


CORE sends SIP REFER request including the 
GRUU of the target device and the IPTV 
Content Marker to AS via ISC 




7 


SIP/SDP 


AS sends SIP REFER request including the 
GRUU of the target device and the IPTV 
Content Marker to CORE via ISC 




8 


SIP/SDP 


CORE sends SIP REFER request including the 
GRUU of the target device and the IPTV 
Content Marker to CoDs via y2 


^ 




9 


SIP 


CoDs sends SIP 202 ACCRETED to CORE via 
y2 






10 


SIP 


CORE sends SIP 202 ACCRETED to AS via 
ISC 




11 


SIP 


AS sends SIP 202 ACCRETED to CORE via 
ISC 


i 


12 


SIP 


CORE sends SIP 202 ACCRETED to UE via 
Gm 




i 


13 


SIP/SDP 


CoDs sends SIP INVITE to CORE via y2 


14 


> 




SIP/SDP 


CORE sends SIP INVITE to AS via ISC 


15 
16 


^ 

> 

« 


blr/oUr 
SIP/SDP 


Ab SenaS olr INVI l c to OUHb via loU 
CORE sends SIP INVITE to UE B via Gm 


17 
18 
19 






> 


SIP 
SIP 
SIP 


UE B sends SIP 200 OK to GORE via Gm 
CORE sends SIP 200 OK to AS via ISC 
AS sends SIP 200 OK to CORE via ISC 


20 
21 
22 












« 

> 


» 


SIP 
SIP 
SIP 


CORE sends SIP 200 OK to CoDs via y2 
CoDs sends SIP ACK to CORE via y2 
CORE sends SIP ACK to AS via ISC 
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Step 


Direction 


Protocol 


Comment 




U 
s 
e 
r 


U 

E 
A 


U 

E 
B 


c 


R 

E 


A 
S 


C 
o 
D 
s 






23 
















SIP 


AS sends SIP ACK to CORE via ISC 


i 


24 


> 


SIP 


CORE sends SIP ACK to UE B via Gm 


i 


25 


» 


SIP 


UE B sends SIP NOTIFY to CORE via y2 


26 




SIP 


CORE sends SIP NOTIFY to AS via ISC 


27 




SIP 


AS sends SIP NOTIFY to CORE via ISC 


i 


28 


> 


SIP 


CORE sends SIP NOTIFY to UE A via Gm 


< 




29 




> 


SIP 


UE A sends SIP 200 OK to CORE via Gm 


30 






SIP 


CORE sends SIP 200 OK to AS via ISC 


31 




SIP 


AS sends SIP 200 OK to CORE via ISC 


^ 


32 




SIP 


CORE sends SIP 200 OK to CoDs via y2 




^ 


33 






SIP 


CoDs sends SIP BYE to CORE via y2 


i 




34 


> 




SIP 


CORE sends SIP BYE to AS via ISC 


35 




SIP 


AS sends SIP BYE to CORE via ISC 


i 


36 


> 


SIP 


CORE sends SIP BYE to UE A via Gm 


^ 




37 




» 


SIP 


UE A sends SIP 200 OK to CORE via Gm 


38 






SIP 


CORE sends SIP 200 OK to AS via ISC 


39 




SIP 


AS sends SIP 200 OK to CORE via ISC 


i 


40 




SIP 


CORE sends SIP 200 OK to CoDs via y2 




^ 


41 


N. 




RTSP 


UE A sends a RTSP PLAY including the current 
play time to CoDs via Xc 






42 


RTSP 


CoDs sends RTSP 200 OK to UE A via Xc 


i 




43 








Verify that UE A session is terminated 


i 


44 






Verify that UE B displays the same content from 
the correct play time 


i 





















Refer to test description TDIMSJPTVCoDIOOOl (4.4.5.1) for normal session termination. 
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